2W字長文吐血整理 Docker&雲原生
Docker 和 雲原生
一、概念介紹
1.1 Docker
Docker 是一個開源的應用容器引擎,讓開發者可以打包他們的應用以及依賴包到一個可移植的映象中,然後釋出到任何流行的 Linux或Windows作業系統的機器上,也可以實現虛擬化。容器是完全使用沙箱機制,相互之間不會有任何介面。
- Docker歷史
軟體開發最大的麻煩事之一,就是環境配置。使用者計算機的環境都不相同,你怎麼知道自家的軟體,能在那些機器跑起來
- 比如你編寫了一個Web應用,本地除錯沒有問題,想發給你的朋友看看或者部署到遠端伺服器。那麼首先你需要配置相同的環境(資料庫、Web伺服器),不一定保證能夠啟動起來
- 開發和測試同學最常反饋的:"它在我的本地是可以的",言下之意就是,其他機器很可能跑不了。
為了解決這個問題,出現以物理機和虛擬機器為主體的開發運維環境,向以容器為核心的基礎設施的轉變過程
半個世紀以前,集裝箱發揮了巨大的力量,改變了整個運輸產業(集裝箱化作業的興起)。可以說是“沒有集裝箱,就不會有全球化”。
而Docker橫空出世,是雲服務市場的重要拐點。Docker,相當於雲服務市場的“箱子”,對Container(容器)技術的運用代表新的時代來臨。DockerLogo:鯨魚就是作業系統,通過身上的集裝箱(Container)來將不同種類的貨物進行隔離;而不是通過生出很多小鯨魚(Guest OS)來承運不同種類的貨物。
那麼物理機/虛擬機器為什麼會被容器替代?
虛擬機器(VM)和Docker經常在一個上下文出現,因為它們都是用於隔離環境
從上圖可以看出,和平時使用中總結下來,虛擬機器和 Docker 容器的差異。虛擬機器需要模擬硬體,執行整個作業系統,不但體積臃腫還記憶體佔用高,程式效能也會受到影響
虛擬機器 | Docker |
---|---|
硬體級程序隔離 | 作業系統級程序隔離 |
每個虛擬機器都有一個單獨的作業系統 | 每個容器可以共享作業系統 |
在幾分鐘內啟動 | 在幾秒鐘內啟動 |
虛擬機器只有幾 GB | 容器是輕量級的 (KBs/MBs) |
更多資源使用 | 更少的資源使用 |
虛擬機器可以輕鬆遷移到新主機 | 容器被銷燬並重新建立而不是移動 |
建立VM需要相對較長的時間 | 容器可以在幾秒鐘內建立 |
Docker打包機制
但是容器取代虛擬機器真正的原因還是Docker發明的映象
而Docker 映象解決的,恰恰就是打包這個根本性的問題。所謂 Docker 映象,其實就是一個壓縮包。但是這個壓縮包裡的內容,比 PaaS 的應用可執行檔案 + 啟停指令碼的組合要豐富多了。實際上,大多數 Docker 映象是直接由一個完整作業系統的所有檔案和目錄構成的,所以這個壓縮包裡的內容跟你本地開發和測試環境用的作業系統是完全一樣的。
只要有這個壓縮包在手,你就可以使用某種技術建立一 個“沙盒”,在“沙盒”中解壓這個壓縮包,然後就可以執行你的程式了。
這種機制直接打包了應用執行所需要的整個作業系統,從而保證了本地環境和雲端環境的高度一致
- Docker的“沙盒”實現
容器技術的核心功能,就是通過約束和修改程序的動態表現,從而為其創造出一個"邊界",對於 Docker 等大多數 Linux 容器來說,都是使用 Cgroups 和 Namespace 機制創建出來的 隔離環境,基於AUFS(Advance Union File System) 檔案系統進行打包
- cgroup:資源分配和管理
- namspsce:隔離(使用者/網路/程序等)隔離
- aufs:映象打包機制
Cgroups
Linux Cgroups 的全稱是 Linux Control Group。它最主要的作用,就是限制一個程序組能夠使用的資源上限,包括 CPU、記憶體、磁碟、網路頻寬等等。
此外,Cgroups 還能夠對程序進行優先順序設定、審計,以及將程序掛起和恢復等操作。在今天的分享中,只重點探討它與容器關係最緊密的“限制”能力。在 Linux 中,Cgroups 給使用者暴露出來的操作介面是檔案系統,即它以檔案和目錄的方式組織在作業系統的 /sys/fs/cgroup 路徑下。可以用 mount 指令把它們展示出來,這條命令是:
[root@k8s-demo-master ~]# mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
在 /sys/fs/cgroup 下面有很多諸如 cpuset、cpu、 memory 這樣的子目錄, 也叫子系統。這些都是我這臺機器當前可以被 Cgroups 進行限制的資源種類
[root@k8s-demo-master ~]# cd /sys/fs/cgroup/cpu
[root@k8s-demo-master cpu]# ls
aegis cgroup.procs cpuacct.usage cpuacct.usage_percpu_sys cpuacct.usage_user cpu.rt_period_us cpu.stat release_agent
assist cgroup.sane_behavior cpuacct.usage_all cpuacct.usage_percpu_user cpu.cfs_period_us cpu.rt_runtime_us kubepods system.slice
cgroup.clone_children cpuacct.stat cpuacct.usage_percpu cpuacct.usage_sys cpu.cfs_quota_us cpu.shares notify_on_release tasks
[root@k8s-demo-master cpu]# cat cpuacct.usage
34538850584425
[root@k8s-demo-master cpu]# cat cpu.cfs_quota_us
20
它意味著在每 100 ms 的時間裡,被該 控制組限制的程序只能使用 20 ms 的 CPU 時間,也就是說這個程序只能使用到 20% 的 CPU 頻寬。如果在sys/fs/cgroup/cpu目錄下建立一個目錄,視為”控制組“,並且新建cpu.cfs_quota_us的限制檔案和tasks對應的程序id檔案,就能夠達到對指定的程序id進行限制
Linux Cgroups 的設計還是比較易用的,簡單粗暴地理解呢,它就是一個子系統目錄加上一組資源限制檔案的組合。而對於 Docker 等 Linux 容器專案來說,它們只需要在每個子系統下面,為每個容器建立一個控制組(即建立一個新目錄),然後在啟動容器程序之後, 把這個程序的 PID 填寫到對應控制組的 tasks 檔案中就可以了。
我們在 Docker 裡最開始執行的 /bin/sh,就是這個容器內部的第 1 號程序 (PID=1),而這個容器裡一共只有兩個程序在執行。這就意味著,前面執行的 /bin/sh, 以及我們剛剛執行的 ps。已經被 Docker 隔離在了一個跟宿主機完全不同的世界當中。
# wangjun @ LPT004412 in ~ [17:03:04]
$ docker exec -it 9bf2d02c1236 /bin/sh
/ # ps
PID USER TIME COMMAND
1 root 0:00 sh
24 root 0:00 /bin/sh
31 root 0:00 ps
/ # exit
# wangjun @ LPT004412 in ~ [17:04:06] C:130
$ ps -ef
UID PID PPID C STIME TTY TIME CMD
0 1 0 0 1:14下午 ?? 0:32.45 /sbin/launchd
0 294 1 0 1:14下午 ?? 0:28.60 /usr/libexec/logd
名稱空間 (namespaces) 是 Linux 為我們提供的用於分離程序樹、網路介面、掛載點以及程序間通訊等資源的方法。
分類 | 系統呼叫引數 | 相關核心版本 | 隔離內容 |
---|---|---|---|
Mount namespaces | CLONE_NEWNS | Linux 2.4.19 | 掛載點(檔案系統) |
UTS namespaces | CLONE_NEWUTS | Linux 2.6.19 | 主機名和域名 |
IPC namespaces | CLONE_NEWIPC | Linux 2.6.19 | 訊號量、訊息佇列和共享記憶體 |
PID namespaces | CLONE_NEWPID | Linux 2.6.24 | 程序編號 |
Network namespaces | CLONE_NEWNET | 始於 Linux 2.6.24 完成於 Linux 2.6.29 | 網路裝置、網路棧、埠等 |
User namespaces | CLONE_NEWUSER | 始於 Linux 2.6.23 完成於 Linux 3.8) | 使用者和使用者組 |
在 Linux 系統中建立執行緒 的系統呼叫是 clone(),比如:
int pid = clone(main_function, stack_size, SIGCHLD, NULL)
這個系統呼叫就會為我們建立一個新的程序,並且返回它的程序號 pid。
當我們用 clone() 系統呼叫建立一個新程序時,就可以在引數中指定 CLONE_NEWPID 引數,比如:
int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);
這時,新建立的這個程序將會“看到”一個全新的程序空間,在這個程序空間裡,它的 PID 是 1。之所以說“看到”,是因為這只是一個“障眼法”,在宿主機真實的程序空間裡,這個程序的 PID 還是真實的數值,比如 100。
所以在使用 Docker 的時候,可以發現並沒有一個真正的“Docker 容器”執行在宿主機裡面。Docker 專案幫助使用者啟動的,還是原來的應用程序,只不過在建立這些程序時,Docker 為它們加上了各種各樣的 Namespace 引數。
AUFS解決了映象打包的問題,Docker 映象其實本質就是一個壓縮包,我們可以使用下面的命令將一個 Docker 映象中的檔案匯出:
$ docker export $(docker create busybox) | tar -C rootfs -xvf -
$ ls
bin dev etc home proc root sys tmp usr var
你可以看到這個 busybox 映象中的目錄結構與 Linux 作業系統的根目錄中的內容並沒有太多的區別,可以說 Docker 映象就是一個檔案。
Docker 中的每一個映象都是由一系列只讀的層組成的,Dockerfile 中的每一個命令都會在已有的只讀層上建立一個新的層:
AUFS 作為聯合檔案系統,它能夠將不同資料夾中的層聯合(Union)到了同一個資料夾中,這些資料夾在 AUFS 中稱作分支,整個『聯合』的過程被稱為聯合掛載(Union Mount):
dive命令下面的這張圖片非常好的展示了組裝的過程,每一個映象層都是建立在另一個映象層之上的,同時所有的映象層都是隻讀的,只有每個容器最頂層的容器層才可以被使用者直接讀寫,所有的容器都建立在一些底層服務(Kernel)上,包括名稱空間、控制組、rootfs 等等,這種容器的組裝方式提供了非常大的靈活性,只讀的映象層通過共享也能夠減少磁碟的佔用。
![](/Users/wangjun/Library/Application Support/typora-user-images/image-20220310193950144.png)
- 基本概念
- Docker Client : Docker提供給使用者的客戶端。
- Docker Daemon : Docker服務的守護程序。Daemon會接收Docker Client發過來的指令,並對伺服器的進行具體操作。
- Docker Images : 俗稱Docker的映象
- Docker Registry : 這個可認為是Docker Images的倉庫
- Docker Container : 俗稱Docker的容器。Container是真正跑專案程式、消耗機器資源、提供服務的地方,Container通過Images啟動
Docker好比汽車引擎,
Dockerfile相當於汽車藍圖,
Docker image(映象)就是汽車樣板,
Docker container(容器)類似於汽車的零部件,
Docker Registry可以看作是4s店,
Docker Compose就像老司機,
Docker Volume就像是汽車的油箱, 如果把容器間內的io資料流比喻成汽油,
Docker Swarm(或者K8s)就是交通樞紐。
- 基本命令
首先要在宿主機上安裝Docker,Docker安裝參考官方安裝文件。 Docker命令也比較類似Git,支援push以及pull操作上傳以及下載Docker映象。 檢視當前Docker的版本
docker version
檢視當前系統Docker資訊
docker info
檢視宿主機上的映象,Docker映象儲存在/var/lib/docker
目錄下:
docker images
從Docker hub上下載某個映象:
docker pull ubuntu:latest
docker pull ubuntu:latest
執行docker pull ubuntu
會將Ubuntu這個倉庫下面的所有映象下載到本地repository。
啟動一個容器使用docker run
:
docker run -i -t ubuntu /bin/bash 啟動一個容器
docker run -i -t --rm ubuntu /bin/bash --rm表示容器退出後立即刪除該容器
docker run -t -i --name test_container ubuntu /bin/bash --name指定容器的名稱,否則會隨機分配一個名稱
docker run -t -i --net=host ubuntu /bin/bash --net=host容器以Host方式進行網路通訊
docker run -t -i -v /host:/container ubuntu /bin/bash -v繫結掛在一個Volume,在宿主機和Docker容器中共享檔案或目錄
檢視當前有哪些容器正在執行,使用docker ps
:
wangjun @ LPT004412:$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
50a1261f7a8b docker_test:latest "/bin/bash" 7 seconds ago Up 6 seconds sleepy_ptolemy
# 目前只有一個container id為50a1261f7a8b的容器正在執行
啟動或停止某個container使用docker start/stop container_id
:
wangjun @ LPT004412:$ docker stop 50a1261f7a8b
50a1261f7a8b
wangjun @ LPT004412:$ docker ps -a | grep 50a1261f7a8b
50a1261f7a8b docker_test:latest "/bin/bash" 2 minutes ago Exited (0) 14 seconds ago sleepy_ptolemy
#執行docker stop後,該容器的狀態變更為Exited
使用docker commit
可以將container的變化作為一個新的映象,比如:
wangjun @ LPT004412:$ docker commit -m="test docker commit" 50a1261f7a8b docker_test
55831c956ebf46a1f9036504abb1b29d7e12166f18f779cccce66f5dc85de38e
wangjun @ LPT004412:$ docker images | grep docker_test
docker_test latest 55831c956ebf 10 seconds ago 290.7 MB
除了從Docker hub上下載映象,也可以寫Dockerfile建立一個映象,Dockerfile如下所示:
wangjun @ LPT004412:/tmp/docker(0)$ cat Dockerfile
FROM ubuntu:12.04
MAINTAINER Your Name
RUN apt-get update
RUN apt-get install -y python-software-properties python-pip
ADD myproject /opt/code
RUN pip install -r /opt/code/requirement.txt
寫完Dockerfile,在Dockerfile所在目錄執行docker build
建立映象:
docker build -t docker_test .
docker run -i -t docker_test /bin/bash -c "cd /opt/code;python manage.py runserver 0.0.0.0:8080"
將製作的映象上傳到private registry:
docker tag test docker.example.com/test
docker push docker.example.com/test
經過長時間使用,主機上儲存了很多已無用的映象,想將它們刪除則用docker rm
或者docker rmi
,比如:
docker rm container_id
docker rmi image_id
實戰練習一下~舉個例子
1.2 Kubernetes
https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server
https://mp.weixin.qq.com/s/FEG8kaJRqB0LdvPQ7W-tJQ
雲原生作業系統,宣告式 API 是它的核心,Operator 操控萬物。
Kubernetes 這個名字起源於古希臘,是「舵手」的意思,所以它的 Logo 既像一張漁網,又像一個羅盤。如果 Docker 把自己定位為馱著集裝箱在大海上遨遊的鯨魚,那麼 Kubernetes 就是掌舵大航海時代話語權的舵手,指揮著這條鯨魚按照主人設定的路線巡遊。
Kubernetes在2014年成立,在谷歌的內部集裝箱叢集管理者Borg和Omega的幫助下,擁有超過十多年的生產工作量管理經驗。為整個雲原生生態系統鋪平了道路。
Kubernetes一個用於容器叢集的自動化部署、擴容以及運維的開源平臺。通過Kubernetes,你可以快速有效地響應使用者需求;快速而有預期地部署你的應用;極速地擴充套件你的應用;無縫對接新應用功能;節省資源,優化硬體資源的使用。為容器編排管理提供了完整的開源方案。
容器
我們現在常說的容器一般是指Docker容器,通過容器隔離的特性和宿主機進行解耦,使我們的服務不需要依賴於宿主機而執行,與宿主機互不影響,Docker容器十分輕量。而kubernetes則負責管理服務中所有的Docker容器,建立、執行、重啟與刪除容器。
快速響應
個人理解為兩個方面。一、新增或者修改需求時,可以快速進行部署測試(CICD);二、kubernetes可以根據不同條件進行動態擴縮容,舉個栗子,使用者訪問量突然由1000人上升到100000人時,現有的服務已經無法支撐,kubernetes會自動將使用者服務模組增加更多例項以保證當前的系統訪問量。
擴充套件
在快速響應的特點中已經有所提及,這裡再補充一點: Kubernetes內部有完善的註冊發現機制,當某個服務的例項增加時,kubernetes會自動將其加入服務列表中,免除在傳統運維中需要人工維護服務列表的問題。
對接新應用
kubernetes是一個通用的容器編排框架,支援不同型別的語言,或者是語言無關的,新增加的應用都會以一個新的物件進行接入。
硬體資源
這一點我覺得是kubernetess很基本但是非常重要的一個優點了,kubernetes在部署應用時會自動檢查各個伺服器的cpu與記憶體使用量,同時會根據服務申請的cpu與記憶體資源,將服務部署到最合適的伺服器。(其實這就是容器排程的核心功能了)
Kubernetes歷史
CNCF:https://landscape.cncf.io/
Kubernetes 叢集包含一個 master 和很多 node。Master 是控制叢集的中心,node 是提供 CPU、記憶體和儲存資源的節點。Master 上執行著多個程序,包括面向使用者的 API 服務、負責維護叢集狀態的 Controller Manager、負責排程任務的 Scheduler 等。每個 node 上執行著維護 node 狀態並和 master 通訊的 kubelet,以及實現叢集網路服務的 kube-proxy。
- etcd是Kubernetes的儲存狀態的分散式資料庫,採用raft協議作為一致性演算法(raft協議原理可參見一個動畫演示http://thesecretlivesofdata.com/raft/)。
- API Server元件主要提供認證與授權、執行一組准入控制器以及管理API版本等功能,通過REST API向外提供服務,允許各類元件建立、讀取、寫入、更新和監視資源(Pod, Deployment, Service等)。
- Scheduler元件,根據叢集資源和狀態選擇合適的節點用於建立Pod。
- Controller Manager元件,實現ReplicaSet的行為。
- Kubelet元件,負責監視繫結到其所在節點的一組Pod,並且能實時返回這些Pod的執行狀態。
部署 - Deployment
類似於Docker中的映象Image,也就是容器(Pods)例項的模板,容器例項是根據Deploy創建出來的。在Deployment物件中會寫明容器的映象,容器的版本,容器要部署的數量等資訊。
容器組 - Pods
Pods是Kubernetes中的最小管理單元,Pods和Docker中的容器可以理解為包含關係,在Pods中可以包含有多個Docker容器,例如有ServiceA和ServiceB,ServiceA高度依賴ServiceB(需要共享主機的相同檔案),這時就可以將ServiceA與ServiceB放在同一個Pods中,當做一個整體來管理。如果分開部署當然也可以,不過會小號額外的資源或者產生其他不必要的麻煩。
服務 - Service
Service是一個物件,這個物件有自己的IP,也就是ClusterIP,可以理解為就是下層服務的負載均衡。
路由 - Ingress
無論是容器組還是Service,外網都是無法直接訪問的,Ingress就可以通過一個負載IP與Kubernetes叢集內部進行通訊,一般會和Service物件進行配合使用。
配置項 - ConfigMap
簡單理解為一個管理配置的物件,可以將專案的配置寫入到ConfgiMap中,專案中的配置使用相應的變數名就可以讀取相應的變數值。
Kubernetes由Master節點和Worker節點組成。master節點是Kubernetes的大腦,而woker節點則是kubernetes中實際執行服務的勞動者。
Master主要由ETCD/Controller Manager/Api Server/Schedular能成,
ETCD
主要負責儲存各個woker節點的狀態和其它相關資料,可以理解為kubernetes的資料庫。
Controller Manager
負責維護叢集的狀態,比如故障檢測、自動擴充套件、滾動更新等
Scheduler
負責資源的排程,按照預定的排程策略將Pod排程到相應的機器上
Worker主要由kubelet和kube-proxy組成,一般還會安裝kube-dns元件。
kubelet
負責維護容器的生命週期,同時也負責Volume(CVI)和網路(CNI)的管理;
kube-proxy
負責為Service提供cluster內部的服務發現和負載均衡;
kube-dns
負責為整個叢集提供DNS服務,通過Service名稱訪問相應的服務
Kubernetes命令列示例例子:https://mp.weixin.qq.com/s/bij0kiYK_C6ppcINV0z43g
Kubernetes官方例子:https://mp.weixin.qq.com/s/FWxnDcgCVvVDoStoI3IqbQ https://kubernetes.io/docs/tutorials/kubernetes-basics/
1.3 雲原生
CNCF給出了雲原生應用的三大特徵:
- 容器化封裝:以容器為基礎,提高整體開發水平,形成程式碼和元件重用,簡化雲原生應用程式的維護。在容器中執行應用程式和程序,並作為應用程式部署的獨立單元,實現高水平資源隔離。
- 動態管理:通過集中式的編排排程系統來動態的管理和排程。
- 面向微服務:明確服務間的依賴,互相解耦。
雲原生包含了一組應用的模式,用於幫助企業快速,持續,可靠,規模化地交付業務軟體。雲原生由微服務架構,DevOps 和以容器為代表的敏捷基礎架構組成。
SercieMesh
服務網格(Service Mesh)是處理服務間通訊的基礎設施層。它負責構成現代雲原生應用程式的複雜服務拓撲來可靠地交付請求。在實踐中,Service Mesh 通常以輕量級網路代理陣列的形式實現,這些代理與應用程式程式碼部署在一起,對應用程式來說無需感知代理的存在。
如果用一句話來解釋什麼是 Service Mesh,可以將它比作是應用程式或者說微服務間的 TCP/IP,負責服務之間的網路呼叫、限流、熔斷和監控。對於編寫應用程式來說一般無須關心 TCP/IP 這一層(比如通過 HTTP 協議的 RESTful 應用),同樣使用 Service Mesh 也就無須關心服務之間的那些原本通過服務框架實現的事情,比如 Spring Cloud、Netflix OSS 和其他中介軟體,現在只要交給 Service Mesh 就可以了。
下面以 Istio 為例講解 Service Mesh 如何工作,後續文章將會詳解 Istio 如何在 Kubernetes 中工作。
- Sidecar(Istio 中使用 Envoy 作為 sidecar 代理)將服務請求路由到目的地址,根據請求中的引數判斷是到生產環境、測試環境還是 staging 環境中的服務(服務可能同時部署在這三個環境中),是路由到本地環境還是公有云環境?所有的這些路由資訊可以動態配置,可以是全域性配置也可以為某些服務單獨配置。這些配置是由服務網格的控制平面推送給各個 sidecar 的,
- 當 sidecar 確認了目的地址後,將流量傳送到相應服務發現端點,在 Kubernetes 中是 service,然後 service 會將服務轉發給後端的例項。
- Sidecar 根據它觀測到最近請求的延遲時間,選擇出所有應用程式的例項中響應最快的例項。
- Sidecar 將請求傳送給該例項,同時記錄響應型別和延遲資料。
- 如果該例項掛了、不響應了或者程序不工作了,sidecar 會將把請求傳送到其他例項上重試。
- 如果該例項持續返回 error,sidecar 會將該例項從負載均衡池中移除,稍後再週期性得重試。
- 如果請求的截止時間已過,sidecar 主動標記該請求為失敗,而不是再次嘗試新增負載。
- SIdecar 以 metric 和分散式追蹤的形式捕獲上述行為的各個方面,這些追蹤資訊將傳送到集中 metric 系統。
https://capa-cloud.github.io/capa.io/blog/2022/01/18/capa-mecha-sdk-of-cloud-application-api/
ServiceMesh帶來的新的挑戰
Severless
拿部署一套部落格來說,常見的 Node.js MVC 架構,需要購買雲服務商的 Linux 虛擬機器、RDS 關係型資料庫,做得好的話還要購買 Redis 快取、負載均衡、CDN 等等。再考慮容災和備份,這麼算下來一年最小開銷都在 1 萬元左右。但如果你用 Serverless 的話,這個成本可以直接降到 1000 元以下。
可預見時間內的雲原生的終極形式,真正的按需使用和按量付費。
Serverless架構能夠讓開發者在構建應用的過程中無需關注計算資源的獲取和運維,由平臺來按需分配計算資源並保證應用執行的SLA(服務等級協議),按照呼叫次數進行計費,有效的節省應用成本。ServerLess的架構如上圖所示。其優點如下所示:
低運營成本/更快的開發速度/提升可維護性/簡化裝置運維
二、如何CICD
持續整合(Continuous integration) / 持續部署(Continuous Deployment)
美團經驗:https://tech.meituan.com/2019/08/22/kubernetes-cluster-management-practice.html
2.2 自己做CICD
[Gitee-Jenkins外掛]https://gitee.com/help/articles/4193#article-header0
三、平時開發中使用Docker
3.1 環境搭建
https://nystudio107.com/blog/dock-life-using-docker-for-all-the-things
四、擴充套件閱讀
4.1 其他
- Docker官方文件 Docker中文社群 Docker-從入門到實踐 Docker-For-Beginnings
- Docker如何執行MacOS Docker-搭建樹莓派
- Kubernetes 中文官方文件 免費學習 Kubernetes 利器
- Kubernetes中文指南/雲原生應用架構實踐手冊
- Kuboard - Kubernetes 多叢集管理介面
- 語雀文件 - Kubernetes運維整理
- Kubernetes 工程師資料合輯,書籍推薦,面試題,精選文章,開源專案,PPT,視訊,大廠資料
- 和我一步步部署 kubernetes 叢集 一條命令部署 Kubernetes 高可用叢集
- Kubernetes 學習筆記
- Jenkins 與 Kubernetes 的 CI 與 CD & Git + Maven + Docker+Kubectl
- Service Mesh 在中國的佈道者和領航者
- Serverless Handbook—無服務架構實踐手冊