這篇文章主要介紹“怎么理解前端領(lǐng)域的Docker與Kubernetes”，在日常操作中，相信很多人在怎么理解前端領(lǐng)域的Docker與Kubernetes問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解前端領(lǐng)域的Docker與Kubernetes”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站制作、網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的建安網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

Docker 安裝

•  Linux Debian/Ubuntu， 安裝 社區(qū)版DockerCE

•  Windows 一鍵安裝

如果是 Windows10， Windows7 將會使用 VirtualBox 安裝 Linux 作為 Docker 的宿主機。

Windows10 Pro 會使用 Hyper-V 安裝 Linux 作為 Docker 的宿主機。

•  macOS 一鍵安裝 

Docker 基本信息

默認(rèn) Docker 存儲位置為 /var/lib/docker，所有的鏡像，容器，卷都會在這里，如果你使用了多硬盤，或者掛載了 SSD 不在 / 上，需要修改默認(rèn)路徑（graph）到合適位置，配置文件為 /etc/docker/daemon.json， 例如

{    "bip": "192.168.0.1/16"，    "graph": "/mnt/ssd/0/docker"  }

Docker 在安裝過程中會自動創(chuàng)建好 docker0 網(wǎng)卡，并分配 ip 給他。

上面指定的 bip 是指定了 docker0 網(wǎng)卡的 ip ， 如果不指定那么在創(chuàng)建 docker0 時會自動根據(jù)主機 ip 選取一個合適的 ip，不過由于網(wǎng)絡(luò)的復(fù)雜性，特別是機房網(wǎng)絡(luò)內(nèi)很容易發(fā)現(xiàn)地址選取沖突，這時候就需要手動指定 bip 為一個合適的值。docker 的 ip 選取規(guī)則這篇文章分析的很好， 可以參考 https://blog.csdn.net/longxin... 。

安裝并啟動后可以通過 docker info 查看Docker的一些配置信息。

Docker hello world

Docker 檢查安裝是否正常的第一個測試命令很簡單。

docker run hello-world

首先他會去 Docker Hub 上下載 hello-world 這個鏡像，然后在本地運行這個鏡像，啟動后的這個 Docker 服務(wù)稱之為容器。容器創(chuàng)建后就會執(zhí)行規(guī)定的入口程序，程序執(zhí)行向流中輸出了一些信息后退出，容器也會隨著這個入口程序的結(jié)束而結(jié)束。

•  查看所有容器 

docker ps -a

輸出如下:

cf9a6bc212f9 hello-world "/hello" 28 hours ago Exited (0) 3 min

第一列為容器 id， 很多針對容器的操作都需要這個 id， 例如下面一些常用的操作。

docker rm container_id  docker stop container_id  docker start container_id  docker describe container_id

這里有個docker start container_id， 啟動一個容器，說明容器即使退出后其資源依然存在，還可以使用docker start重啟這個容器。要想讓容器退出后自動刪除可以在docker run時指定--rm參數(shù)。

當(dāng)我們運行這個命令時 Docker 會去下載 hello-world 這個鏡像緩存到本地，這樣當(dāng)下次再運行這條命令時就不需要去源中下載。

•  查看本地鏡像 

docker images

運行 Nginx

Nginx 作為使用廣泛的 Web 服務(wù)器在 Docker 世界里也是同樣流行， 常常用來啟動一個網(wǎng)絡(luò)服務(wù)驗證網(wǎng)絡(luò)配置情況， 使用下面這條命令啟動 Nginx 容器 docker run --rm -p 80:80 nginx。

訪問 localhost:80 端口即可看到 Nginx 服務(wù)啟動， 控制臺中可以看到 Nginx 服務(wù)的日志輸出。

因為 Docker 內(nèi)的網(wǎng)絡(luò)與外部世界是隔離的，所以我們需要手動指定端口轉(zhuǎn)發(fā) -p 80:80 來顯式將宿主機的80(前)轉(zhuǎn)發(fā)到容器的80端口， 暴露端口是我們提供服務(wù)最常用的使用方式之一。 也有一些其他類型的服務(wù)，例如日志處理，數(shù)據(jù)收集需要共享數(shù)據(jù)卷才能提供服務(wù)，所有這些都需要我們在啟動容器時顯式指定。

一些常見的啟動參數(shù):

•  -p 本機端口:容器端口 映射本地端口到容器

•  -P 將容器端口映射為本機隨機端口

•  -v 本地路徑或卷名:容器路徑 將本地路徑或者數(shù)據(jù)卷掛載到容器的指定位置

•  -it 作為交互式命令啟動

•  -d 將容器放在后臺運行

•  --rm 容器退出后清除資源

Docker是如何工作的

Docker 的底層核心原理是利用了 Linux 內(nèi)核的 namespace 以及 cgroup 特性，其中 namespace 進行資源隔離，cgroup 進行資源配額， 其中 Linux 內(nèi)核中一共有 6 種 namespace，分別對應(yīng)如下。

Namespace	系統(tǒng)調(diào)用函數(shù)	隔離內(nèi)容
UTS	CLONE_NEWUTS	主機與域名
IPC	CLONE_NEWIPC	信號量、消息隊列和共享內(nèi)存
PID	CLONE_NEWPID	進程編號
Network	CLONE_NEWNET	網(wǎng)絡(luò)設(shè)備、網(wǎng)絡(luò)棧、端口等
Mount	CLONE_NEWNS	掛載點(文件系統(tǒng))
User	CLONE_NEWUSER	用戶和用戶組

在系統(tǒng)調(diào)用中有三個與namespace有關(guān)的函數(shù):

1.  clone http://man7.org/linux/man-pag... 

如果我想讓子進程擁有獨立的網(wǎng)絡(luò)地址，TCP/IP 協(xié)議棧，可以下面這樣指定。

clone(cb， *stack ， CLONE_NEWNET， 0)

1.  unshare http://man7.org/linux/man-pag... 

將當(dāng)前進程轉(zhuǎn)移到新的 namespace 中， 例如使用 fork 或 vfork 創(chuàng)建的進程將默認(rèn)共享父級資源，使用 unshare 將子進程從父級取消共享。

1.  setns http://man7.org/linux/man-pag... 

給指定的PID指定 namespace， 通常用于共享 namespace。

Linux 在內(nèi)核層支持了在系統(tǒng)調(diào)用中隔離 namespace， 通過給一個進程分配單獨的 namespace 從而讓其在各個資源維度進行隔離，每個進程都能獲取到自己的主機名，IPC， PID， IP， 根文件系統(tǒng)，用戶組等信息，就像在一個獨占系統(tǒng)中，不過雖然資源進行了隔離，但是內(nèi)核還是共享同一個，這也是比傳統(tǒng)虛擬機輕量的原因之一。

另外只有資源進行隔離還不夠，要想保證真正的故障隔離，互不影響， 還需要對針對 CPU， 內(nèi)存，GPU 等進行限制，因為如果一個程序出現(xiàn)死循環(huán)或者內(nèi)存泄露也會導(dǎo)致別的程序無法運行。 資源配額是使用內(nèi)核的 cgroup 特性來完成，想了解細(xì)節(jié)的同學(xué)可以

（另外強烈推薦在 Linux 4.9 以上的內(nèi)核跑容器，Linux 3.x 中有已知內(nèi)核不穩(wěn)定導(dǎo)致主機重啟的問題）

Docker 網(wǎng)絡(luò)

一個容器要想提供服務(wù)，就需要將自身的網(wǎng)絡(luò)暴露出去。Docker 是與宿主機上的環(huán)境是隔離的，要想暴露服務(wù)就需要顯示告訴 Docker 哪些端口允許外部訪問，在運行 docker run -p 80:80 nginx 時這里就是將容器內(nèi)部的 80 端口暴露到宿主機的 80 端口上，具體的端口轉(zhuǎn)發(fā)下面會具體分析一下。容器的網(wǎng)絡(luò)部分是容器中最重要的部分，也是構(gòu)建大型集群的基石，在我們部署 Docker 的應(yīng)用時，需要要對網(wǎng)絡(luò)有個基本的了解。

Docker 提供了四種網(wǎng)絡(luò)模式，分別為 Host， Container， None， Bridge 使用 --net 進行指定

Host 模式:

docker run --net host nginx

Host 模式不會單獨為容器創(chuàng)建 network namespace， 容器內(nèi)部直接使用宿主機網(wǎng)卡，此時容器內(nèi)獲取 ip 為宿主機 ip，端口綁定直接綁在宿主機網(wǎng)卡上，優(yōu)點是網(wǎng)絡(luò)傳輸時不用經(jīng)過 NAT 轉(zhuǎn)換，效率更高速度更快。

Container 模式:

docker run --net container:xxx_containerid nginx

和指定的 container 共享 network namespace， 共享網(wǎng)絡(luò)配置，ip 地址和端口，其中無法共享網(wǎng)絡(luò)模式為 Host 的容器。

None 模式:

docker run --net none busybox ifconfig

指定為 None 模式的容器內(nèi)將不會分配網(wǎng)卡設(shè)備，僅有內(nèi)部 lo 網(wǎng)絡(luò)。

Bridge 模式

docekr run --net bridge busybox ifconfig

該模式為默認(rèn)模式，容器啟動時會被分配一個單獨的 network namespace，同時 Docker 在安裝/初始化時會在宿主機上創(chuàng)建一個名為 docker0 的網(wǎng)橋，該網(wǎng)橋也作為容器的默認(rèn)網(wǎng)關(guān)，容器網(wǎng)絡(luò)會在該網(wǎng)關(guān)網(wǎng)段內(nèi)進行 ip 的分配。

當(dāng)我執(zhí)行 docker run -p 3000:80 nginx 時，Docker 會在宿主機上創(chuàng)建下面一條 iptable 轉(zhuǎn)發(fā)規(guī)則。

最底下的規(guī)則顯示當(dāng)外部請求主機網(wǎng)卡 3000 端口時將它進行目的地址轉(zhuǎn)換(DNAT)， 目的地址修改為 172.18.0.2，端口修改為 80，修改好目的地址后流量會從本機默認(rèn)網(wǎng)卡經(jīng)過 docker0 轉(zhuǎn)發(fā)到對應(yīng)的容器，這樣當(dāng)外部請求宿主機的 3000 端口，內(nèi)部會將流量轉(zhuǎn)發(fā)給內(nèi)部容器服務(wù)，從而實現(xiàn)服務(wù)的暴露。

同樣 Docker 內(nèi)部訪問外部接口也會進行源地址轉(zhuǎn)換(SNAT)， 容器內(nèi)部請求 google.com， 服務(wù)器上收到的將是主機網(wǎng)卡的 ip。

Bridge 模式由于多了一層 NAT 轉(zhuǎn)換所以效率會比 Host 模式差一些，但是能夠很好的隔離外部網(wǎng)絡(luò)環(huán)境，讓容器獨享 ip 且具有完整的端口空間。

上面四種網(wǎng)絡(luò)模式是 Docker 自帶的幾種工作方式，但是部署 Kubernetes 需要所有的容器都工作在一個局域網(wǎng)中，所以在部署集群時需要多主機網(wǎng)絡(luò)插件的支持。

Flannel

多主機網(wǎng)絡(luò)解決方案有 CNCF 推出的 CNI 規(guī)范以及 Docker 自帶的 CNM 方案，但是目前大家用的最多的還是 CNI 規(guī)范，其中一種實現(xiàn)就是 Flannel。

Flannel 使用了報文嵌套技術(shù)來解決多主機網(wǎng)絡(luò)互通問題，將原始報文進行封包，指定包ip為目的主機地址，等包到達主機后再進行拆包傳送到對應(yīng)的容器。下圖顯示 flannel 使用效率更高的 UDP 協(xié)議來在主機間傳輸報文。

目前主流跨主機通信目前常用的有三種，各有優(yōu)缺，視場景選擇:

•  overlay， 即上面的報文嵌套。

•  hostgw 通過修改主機路由表實現(xiàn)轉(zhuǎn)發(fā)，不需要拆包和封包，效率更高，但同樣限制比較多，只適合在相同局域網(wǎng)中的主機使用。

•  使用軟件實現(xiàn)的 BGP（邊界網(wǎng)關(guān)協(xié)議）以此向網(wǎng)絡(luò)中的路由器廣播路由規(guī)則。和 hostgw 一樣不需要拆包，但是實現(xiàn)成本較高。

有了CNI才能在此基礎(chǔ)上構(gòu)建 Kubernetes 集群。

Kubernetes 介紹

在小規(guī)模場景下使用 Docker 可以一鍵部署應(yīng)用確實很方便，達到了一鍵部署的目的，但是當(dāng)出現(xiàn)需要在幾百臺主機上進行多副本部署，需要管理這么多主機的運行狀態(tài)以及服務(wù)的故障時需要在其他主機重啟服務(wù)，想象一下就知道手動的方式不是一種可取的方案，這時候就需要利用 Kubernetes 這種更高維度的編排工具來管理了。Kubernetes 簡稱 K8S， 簡單說 K8S 就是抽象了硬件資源，將 N 臺物理機或云主機抽象成一個資源池，容器的調(diào)度交給 K8S 就像親媽一樣照顧我們的容器，CPU 不夠用就調(diào)度到一臺足夠使用的機器上，內(nèi)存不滿足要求就會尋找一臺有足夠內(nèi)存的機器在上面創(chuàng)建對應(yīng)的容器，服務(wù)因為某些原因掛了， K8S 還會幫我們自動遷移重啟， 簡直無微不至，至尊享受。我們作為開發(fā)者只關(guān)心自己的代碼，應(yīng)用的健康由 K8S 保證。

這里就不介紹具體的安裝方式了，如果使用 Windows 或者 MacOS 可以直接使用 Docker Desktop 下的 Kubernetes 選項一鍵安裝單主機集群，也可以使用 kind 工具 在本地模擬多集群 K8S。

K8S 調(diào)度的基本單位為 pod， 一個 pod 表示一個或多個容器。引用一本書里所說

之所以沒有使用容器作為調(diào)度單位，是因為單一的容器沒有構(gòu)成服務(wù)的概念；例如 Web 應(yīng)用做了前后端分例，需要一個 NodeJS 與 Tomcat 才能組成一個完整的服務(wù)，這樣就需要部署兩個容器來實現(xiàn)一個完整的服務(wù)，雖然也可以把他們都放到一個容器里，但這顯然違反了一個容器即一個進程的核心思想 --《Service Mesh實戰(zhàn) - 用 istio軟負(fù)載實現(xiàn)服務(wù)網(wǎng)格》

K8S 與傳統(tǒng) IaaS 系統(tǒng)的不同:

IaaS 就是 Infrastructure as a service， 所謂基礎(chǔ)設(shè)施即服務(wù)，開發(fā)者想要上線一個新應(yīng)用需要申請主機，ip， 域名等一系列資源，然后登錄主機自行搭建所需環(huán)境，部署應(yīng)用上線，這樣不僅不利于大規(guī)模操作，而且還增加了出錯的可能，運維或開發(fā)這常常自己寫腳本自動化完成，遇到一些差異再手動修改腳本，非常痛苦。

K8S 則是將基礎(chǔ)設(shè)施可編程化，由原來的人工申請改為一個清單文件自動創(chuàng)建，開發(fā)者只需要提交一份文件，K8S 將會自動為你分配創(chuàng)建所需的資源。對這些設(shè)施的 CRUD 都可以通過程序的方式自動化操作。

為了了解 K8S 的基礎(chǔ)概念，下面來部署一個 Node SSR 應(yīng)用:

初始化應(yīng)用模板

npm install create-next-app  npx create-next-app next-app  cd next-app

創(chuàng)建好工程后給添加一個 Dockerfile 用來構(gòu)建服務(wù)的鏡像

Dockerfile

FROM node:8.16.1-slim as build  COPY ./ /app  WORKDIR /app  RUN npm install  RUN npm run build  RUN rm -rf .git  FROM node:8.16.1-slim  COPY --from=build /app /  EXPOSE 3000  WORKDIR /app  CMD ["npm"， "start"]

這個 Dockerfile 做了兩部分優(yōu)化

1.  使用精簡版的 node 基礎(chǔ)鏡像， 大大減少鏡像體積

2.  使用分步構(gòu)建的方式， 能夠減少鏡像層數(shù)以及移除臨時文件從而減少了鏡像體積。

構(gòu)建鏡像

docker build . --tag next-app

之后我們就可以向 Kubernetes 提出我們應(yīng)用的要求了。為了保證高可用，服務(wù)至少創(chuàng)建兩個副本，我們還需要一個應(yīng)用的域名當(dāng)這個域名請求到我們集群上時自動轉(zhuǎn)發(fā)到我們的服務(wù)上。那么我們對應(yīng)的配置文件就可以這么寫

Deployment.yaml

apiVersion: extensions/v1beta1  kind: Ingress  metadata:    name: app-ingress  spec:    rules:    - host: next-app-server      http:        paths:        - backend:            serviceName: app-service            servicePort: 80  ---  kind: Service  apiVersion: v1  metadata:    name: app-service  spec:    selector:      app: web    ports:    - port: 80      targetPort: 3000  ---  apiVersion: apps/v1  kind: Deployment  metadata:    name: app-deployment  spec:    replicas: 2    selector:      matchLabels:        app: web    template:      metadata:        labels:          app: web      spec:        containers:        - image: next-app          name: next-app            imagePullPolicy: IfNotPresent          ports:          - containerPort: 3000

上面這個清單告訴 K8S:

•  首先需要一個 Deployment 控制器，鏡像為 next-app， 服務(wù)端口為 3000，給我創(chuàng)建兩個副本。

•  還需要創(chuàng)建一個 Service， 這個 Service 指向由副本控制器創(chuàng)建的幾個 next-app。

•  申請一個 Ingress 入口， 域名為 next-app-server， 其指向剛剛的 Service。

提交這份申請給 K8S。

kubectl apply -f ./Deployment.yaml

接著就可以看到已經(jīng)部署的 pod。

sh-4.4$ kubectl get pod  NAME                              READY     STATUS    RESTARTS   AGE  app-deployment-594c48dbdb-4f4cg   1/1       Running   0          1m  app-deployment-594c48dbdb-snj54   1/1       Running   0          1m

然后瀏覽器打開 Ingress 里配置的域名即可訪問對應(yīng)的應(yīng)用(前提是這個域名能夠打到你的 K8S 集群節(jié)點上)。

上面的清單主要創(chuàng)建了三種最常見資源來保證服務(wù)的運行， 這也是 Kubernetes 的最主要的三類資源。

•  Ingress

L7層負(fù)載均衡配置， 可以根據(jù)不同的域名或者路徑等信息指向不同的 Service， Ingress 和 Nginx 很像，實際上 Ingress 的一種實現(xiàn)就是 Nginx， 所以可以將 Ingress 來當(dāng)成 Nginx 來用，只           不過我們不需要手動修改 nginx.conf，也不用手動重啟 Nginx 服務(wù)。

•  Service

一組 pod 的抽象，用來選擇提供同一服務(wù)的 pod。 由于 pod 是不穩(wěn)定的，銷毀重建經(jīng)常發(fā)生，pod 的 ip 經(jīng)常發(fā)生變化，所以需要一種抽象的資源 Service 來表示 pod 的位置。 Service 也             是K8S內(nèi)部服務(wù)發(fā)現(xiàn)機制，會自動將 Service 名稱寫入內(nèi)部 DNS 記錄中。

•  Deployment

副本控制器，用來管理維護 pod 的一種機制。通過 Deployment 可以指定副本數(shù)量，發(fā)布策略， 記錄發(fā)布日志并支持回滾。

應(yīng)用發(fā)布系統(tǒng)

K8S 僅僅負(fù)責(zé)容器的編排，實際上如果部署應(yīng)用還需要外部 Pipeline 的支持，代碼的構(gòu)建，靜態(tài)檢查，鏡像的打包由 Pipeline 完成.

;

目前國內(nèi)用的比較多的發(fā)布系統(tǒng)常常由下面幾個服務(wù)組成: GitLab/GitHub, Jenkins, Sonar, Harbor。

K8S 在前端的優(yōu)勢

1.  首先前端應(yīng)用和 Java 不同，一個小型 NodeJS 服務(wù)占用內(nèi)存僅 40M 左右，這意味著如果我們有很多 NodeJS 應(yīng)用，使用 K8S 將節(jié)省大量的硬件資源。

1.  使用容器的思想進行非侵入式日志，性能指標(biāo)收集。

由于容器即是一個進程，所以對容器的監(jiān)控可以看作對我們 NodeJS 進程的監(jiān)控，K8S 生態(tài)里已經(jīng)有很多成熟的容器監(jiān)控方案，例如 Prometheus + Grafana， 使用此可以達到應(yīng)用的非侵入            式性能指標(biāo)的收集包括: 網(wǎng)絡(luò)IO / 磁盤IO / CPU / MEM。

同樣對于日志收集，我們在代碼中可以直接使用console的方式輸出， 在容器維度再使用日志收集服務(wù)進行日志收集，同樣的非侵入式， 代碼層無感知，對開發(fā)者更加友好，將日志和服務(wù)解耦。

1.  前端微服務(wù)架構(gòu)基礎(chǔ)設(shè)施層。

微服務(wù)架構(gòu)是近兩年越來越流行的一種前端架構(gòu)組織方式，微服務(wù)架構(gòu)需要有一種更加彈性靈活的部署方式。 使用 Docker 讓我們在復(fù)雜架構(gòu)中抽象服務(wù)的最小單元，K8S 給自動維護大規(guī)模集群提供了可能?？梢哉f微服務(wù)架構(gòu)天然適合使用 K8S。

K8S 新玩法， 流量分配

K8S 中使用 Service 來抽象一組 pod，而 Service 的選擇器可以動態(tài)變更，所以了我們很多可能的玩法， 比如藍綠發(fā)布系統(tǒng)。

藍綠發(fā)布是指發(fā)布過程中新應(yīng)用發(fā)布測試通過后，通過切換網(wǎng)關(guān)流量， 一鍵升級應(yīng)用的發(fā)布方式， 在 K8S 中通過動態(tài)更新 Service 的選擇器實現(xiàn)不同版本的一鍵切換

下面使用上面的 Next.js 應(yīng)用來演示一下藍綠發(fā)布，倉庫地址

git clone https://github.com/Qquanwei/test-ab-deploy  cd test-ab-deploy  docker build . --tag next-app:stable  kubectl apply -f ./Deployment.yaml

這里會將 next-app:stable 這個鏡像部署到集群中，并且給 pod 打上 version: stable 的tag。

部署后打開顯示如下。

接著，我們部署 test 分支， 這個分支我們會構(gòu)建為 next-app:test 的鏡像，并且部署時給這個pod打上 version: test 的標(biāo)簽。

git checkout test  docker build . --tag next-app:test  kubectl apply -f ./Deployment.yaml

這時候我們一共部署了兩個版本的應(yīng)用，而且都已經(jīng)就緒狀態(tài)。

但是由于我們的 Service 為 version=stable， 所以所有的請求并不會打到 test 版本上，仍然都會請求 stable 的服務(wù)。

當(dāng)我們用其他的方式已經(jīng)驗證 test 版本服務(wù)可用時， 例如配另外一個 Service 用來測試(Good)， 這時候可以下面一條指令切換當(dāng)前的 Service 到 test 應(yīng)用上。

kubectl apply -f ./switch-to-test.yaml

執(zhí)行完這條命令后，刷新頁面可以看到如下。

通過切換 Service 的方式很輕松就實現(xiàn)了藍綠發(fā)布的功能，而且是瞬間完成，因為 Service 是 K8S 里比較輕量的資源，不會和隔壁 Nginx 一樣修改配置就要重啟服務(wù)影響整個線上服務(wù)。當(dāng)然實際生產(chǎn)環(huán)境會比演示更加嚴(yán)謹(jǐn)，可能有專門的平臺以及審核人員進行每個操作的二次驗證。

對于藍綠， 灰度發(fā)布方式，使用 K8S 可以較為輕松地實現(xiàn)，讓我們能夠有更多的方式去驗證想法。不過如果想實現(xiàn)更加高級的流量分配方案（例如A/B發(fā)布），需要復(fù)雜的流量管理策略 （鑒權(quán)，認(rèn)證），就需要用到服務(wù)網(wǎng)格了。

Istio 是目前比較流行的服務(wù)網(wǎng)格框架，相比于 K8S 注重運行容器的管理， Istio 則是更注重容器之間組成的服務(wù)網(wǎng)格的流量傳輸。

下圖是 Istio 捕獲的官方示例的 bookinfo 微服務(wù)中服務(wù)的拓?fù)浣Y(jié)構(gòu)和一些數(shù)據(jù)指標(biāo)。

使用 Istio 有兩個明顯的好處:

1.  Istio 能夠捕捉到服務(wù)間的調(diào)用鏈路，而且不入侵用戶代碼。

2.  Istio 能夠?qū)γ恳粭l連接，進行單獨的管理。

例如，我們可以輕松對的不同版本的 review 應(yīng)用的 v1， v2， v3 版本進行動態(tài)權(quán)重分配。

不僅僅可以對流量權(quán)重分配，而且還可以制定一些A/B方案，例如根據(jù) URL 是否匹配請求不同的版本應(yīng)用，或者根據(jù) Header 種下的 Cookie 進行用戶的區(qū)分，從而請求不同的應(yīng)用。當(dāng)然，面對行業(yè)場景不同，Istio 還會誕生很多有趣的玩法。

不過缺點同樣存在，Istio 實際上也是一個很復(fù)雜的系統(tǒng)，會對性能造成影響，而且會占用不小的系統(tǒng)資源。

到此，關(guān)于“怎么理解前端領(lǐng)域的Docker與Kubernetes”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

名稱欄目：怎么理解前端領(lǐng)域的Docker與Kubernetes
網(wǎng)站網(wǎng)址：http://jinyejixie.com/article4/ghhgie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站改版、搜索引擎優(yōu)化、動態(tài)網(wǎng)站、商城網(wǎng)站、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)