摘要：后面會(huì)涉及以配置文件進(jìn)行部署。的調(diào)度完成，被分配到指定上。這是的一種最終狀態(tài)。圖相較而言，除了提供的基本功能，還支持聲明式的更新和回滾。共享數(shù)據(jù)存儲(chǔ)的問(wèn)題主要分為數(shù)據(jù)臨時(shí)存儲(chǔ)與持久性存儲(chǔ)。

摘要：本文屬于原創(chuàng)，歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)保留出處：https://github.com/jasonGeng88/blog

文章一：帶著問(wèn)題學(xué) Kubernetes 架構(gòu)

Mac OS 10.11.x

kubectl == v1.6.4

minikube == v0.19.1

docker == 1.11.1

使用 minikube 本地搭建 K8S

證明每個(gè) Pod 都有一個(gè) Pause

Pod 的基本使用

Pod 生命周期的各種狀態(tài)

Pod 的管理問(wèn)題

Pod 的多容器場(chǎng)景

Pod 的數(shù)據(jù)共享問(wèn)題

Pod 的網(wǎng)絡(luò)共享的實(shí)現(xiàn)原理

關(guān)于 minikue 的安裝，官方文檔已經(jīng)和詳盡了，這里就不講了。

啟動(dòng) minikube（minikube 是一個(gè)能讓 K8S 本地運(yùn)行的工具）

minikube start 
--vm-driver=xhyve 
--docker-env HTTP_PROXY=http://your-http-proxy-host:your-http-proxy-port  
--docker-env HTTPS_PROXY=http(s)://your-https-proxy-host:your-https-proxy-port

稍微解釋下 --vm-driver=xhyve，如果早期有在 Mac 上安裝 docker 的同學(xué)，應(yīng)該知道 docker 會(huì)在你的電腦上安裝一個(gè) VirtualBox 的虛擬驅(qū)動(dòng)。因?yàn)?docker 支持的只有 Linux 系統(tǒng)，為了讓它能在 Mac 上運(yùn)行，實(shí)際上是運(yùn)行由 VirtualBox 運(yùn)行的虛擬環(huán)境下的。--vm-driver 默認(rèn)的參數(shù)也是 VirtualBox。再來(lái)看 xhyve，它實(shí)際和 VirtualBox 類似，簡(jiǎn)單理解，它是一個(gè)更輕量的虛擬技術(shù)。

如果 docker 下載 gcr.io 鏡像有困難的話，建議配置 docker 代理（這里推薦一個(gè) 多態(tài)代理）。另一種取巧的方式是，先將所需的鏡像通過(guò) docker hub 下載下來(lái)，再通過(guò) docker tag 的方式來(lái)進(jìn)行重命名。

配置本機(jī)的 docker 環(huán)境

上面也說(shuō)了，K8S 是運(yùn)行在 xhyve 建立的虛擬環(huán)境下。所以本地的 docker 命令是無(wú)法連接到 K8S 所依賴的 docker-daemon 的。當(dāng)然，你可以通過(guò) minikube ssh 進(jìn)入虛擬環(huán)境，再使用 docker 命令進(jìn)行觀察。

更直觀的是，通過(guò) eval $(minikube docker-env) 將本地 docker 與 K8S 依賴的 docker 進(jìn)行綁定。這樣在本地就可以通過(guò) docker 命令觀察 K8S 中的容器變化了。

eval $(minikube docker-env -u) 取消與 minikube 中的 docker 進(jìn)行綁定。

好了，K8S 已經(jīng)成功運(yùn)行起來(lái)了。我們下面來(lái)初步觀察一下當(dāng)前 Pod 的運(yùn)行情況，同時(shí)也驗(yàn)證一下上一篇所說(shuō)的“一個(gè) Pod 一個(gè) Pause”的真?zhèn)瘟恕?/p>

查看 K8S 上所有命名空間下的 Pod（剛啟動(dòng)的話，可能需要一定時(shí)間來(lái)拉取相應(yīng)的鏡像。）

kubectl get pods --all-namespaces

可以看到 K8S 一共啟動(dòng)了3個(gè) Pod，并且都是在 kube-system 命名空間下的。具體這3 個(gè) Pod 的作用，大家唉看名字應(yīng)該能猜到一點(diǎn)，不在本文介紹范圍內(nèi)。

驗(yàn)證每個(gè) Pod 內(nèi)都會(huì)運(yùn)行一個(gè) Pause 容器

docker ps

從圖中可以看出，確實(shí)運(yùn)行著3個(gè) pause 容器。同時(shí)運(yùn)行著5個(gè)容器，數(shù)字也與圖1中 READY 的總數(shù)一致（1+3+1）。

先以命令式的方式進(jìn)行啟動(dòng)，這也是最簡(jiǎn)單的啟動(dòng)方式，但不建議用于生產(chǎn)環(huán)境。（后面會(huì)涉及以配置文件進(jìn)行部署。）

kubectl run nginx --image=nginx

注意：在不指定命名空間時(shí)，默認(rèn)為 default，其他指令基本都是如此。

是不是和docker run的命令很像，輕松上手。我們看一下運(yùn)行情況。

圖中顯示，deployment 已經(jīng)被創(chuàng)建?？梢园阉醋魇?Pod 的管理者，是 controller-manager 中的一員（后面還會(huì)講到）。

kubectl get deploy

查看 Pod 列表

kubectl get pods

查看指定 Pod 的詳細(xì)描述

kubectl describe pod $POD_NAME

從圖5中可以看出，Pod 當(dāng)前的狀態(tài)是 Running，如果自己嘗試的話，可能會(huì)遇到其他狀態(tài)。因?yàn)?Pod 所處的生命周期的階段可能不一樣。

下面常見(jiàn)的有這幾種：

Pending：Pod 定義正確，提交到 Master，但其包含的容器鏡像還未完全創(chuàng)建。通常處在 Master 對(duì) Pod 的調(diào)度過(guò)程中。

ContainerCreating：Pod 的調(diào)度完成，被分配到指定 Node 上。處于容器創(chuàng)建的過(guò)程中。通常是在拉取鏡像的過(guò)程中。

Running：Pod 包含的所有容器都已經(jīng)成功創(chuàng)建，并且成功運(yùn)行起來(lái)。

Successed：Pod 中所有容器都成功結(jié)束，且不會(huì)被重啟。這是 Pod 的一種最終狀態(tài)。

Failed：Pod 中所有容器都結(jié)束，但至少一個(gè)容器以失敗狀態(tài)結(jié)束。這也是 Pod 的一種最終狀態(tài)。

從上面的各種狀態(tài)可知，由于種種原因，Pod 可能處于上述狀態(tài)的任何一種。對(duì)于異常的狀態(tài)，K8S 是通過(guò)一種期望值與當(dāng)前值的比對(duì)機(jī)制，來(lái)保證 Pod 的正常運(yùn)行。其內(nèi)部是通過(guò) replicaset（下一代 ReplicationController） 做到的。

kubectl get rs

觀察 replicaset 發(fā)現(xiàn)，存在一個(gè) nginx-xxx 的 replicaset，它的期望值與當(dāng)前值都為1，表示需要一個(gè) Pod，并且已經(jīng)處于 READY 狀態(tài)。

可是我們并沒(méi)有直接的創(chuàng)建過(guò)它。而且一般也不會(huì)直接去使用它。我們通常會(huì)使用上層的 Deployment 來(lái)進(jìn)行調(diào)用，因?yàn)樗€提供了一些其他的特性，如更新與回滾。

驗(yàn)證：當(dāng)手動(dòng)刪除 Pod 時(shí)，Deployment 會(huì)自動(dòng)創(chuàng)建一個(gè)新的 Pod，來(lái)確保與期望值的匹配。

kubectl delete pod $POD_NAME

*Deployment 相較 ReplicationController 而言，除了提供 ReplicationController 的基本功能，還支持聲明式的更新和回滾。
不過(guò)目前還是 beta 版。*

通過(guò)上述驗(yàn)證，我們直接刪除 Pod后，依然會(huì)創(chuàng)建新的 Pod，這是它的保障機(jī)制。我們只有刪除它的上層管理者，即 deployment，那么由它產(chǎn)生的 replicaset 和 Pod 會(huì)自動(dòng)刪除。

kubectl delete deploy $DEPLOY_NAME

為了后面演示的方便，舉一個(gè)服務(wù)自動(dòng)構(gòu)建的例子。（實(shí)用否，大家可以自行判斷）

假設(shè)有兩個(gè)容器，一個(gè)是 nginx 容器，做靜態(tài)服務(wù)器，一個(gè)是 git-sync 容器，用于定時(shí)監(jiān)測(cè) git 倉(cāng)庫(kù)上代碼的變化，拉取最新代碼到本地。這是兩個(gè)獨(dú)立的容器，如果把它們放在一個(gè) Pod 里面，Pod 的特點(diǎn)是內(nèi)部網(wǎng)絡(luò)共享、數(shù)據(jù)空間共享。這樣就大大減少了原先跨容器訪問(wèn)的復(fù)雜度。

這里的例子舉得可能不是特別好，如果涉及跨容器的網(wǎng)絡(luò)通信，那么 Pod 的優(yōu)勢(shì)會(huì)得到更好的體現(xiàn)。

這里通過(guò)配置文件來(lái)啟動(dòng)包含 nginx、git-sync 容器的 Pod，

配置文件 nginx-git.yml 具體內(nèi)容如下：（官方參考文檔）：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-git
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx # 啟動(dòng) nginx 容器
        image: nginx
        volumeMounts: # 掛載數(shù)據(jù)卷
        - mountPath: /usr/share/nginx/html
          name: git-volume
      - name: git-sync # 啟動(dòng) git-sync 容器
        image: openweb/git-sync
        env:
        - name: GIT_SYNC_REPO
          value: "https://github.com/jasonGeng88/test.git"
        - name: GIT_SYNC_DEST
          value: "/git"
        - name: GIT_SYNC_BRANCH
          value: "master"
        - name: GIT_SYNC_REV
          value: "FETCH_HEAD"
        - name: GIT_SYNC_WAIT
          value: "10"
        volumeMounts: # 掛載數(shù)據(jù)卷
        - mountPath: /git
          name: git-volume
      volumes: # 共享數(shù)據(jù)卷
      - name: git-volume
        emptyDir: {}

配置文件有必要的注釋，應(yīng)該比較容易理解，這里簡(jiǎn)單講下兩點(diǎn)：

GIT 倉(cāng)庫(kù)地址下只有一個(gè) index.html 文件，內(nèi)容為：hello world 1!。

關(guān)于共享數(shù)據(jù) volumes 的配置問(wèn)題。共享數(shù)據(jù)存儲(chǔ)的問(wèn)題主要分為：數(shù)據(jù)臨時(shí)存儲(chǔ)與持久性存儲(chǔ)。

臨時(shí)存儲(chǔ)：

volumes:
- name: volume-name
  emptyDir: {}

* 掛載宿主機(jī)存儲(chǔ)：

volumes:
- name: volume-name
  hostPth: 
      path: "/data"

* 當(dāng)然還有網(wǎng)絡(luò)磁盤(pán)存儲(chǔ)等（如谷歌公有云）

注意：即使是臨時(shí)存儲(chǔ)，因?yàn)閿?shù)據(jù)是 Pod 下所有容器共享的，任何一個(gè)容器重啟，數(shù)據(jù)都不會(huì)丟失。當(dāng) Pod 結(jié)束時(shí)，臨時(shí)性數(shù)據(jù)才會(huì)丟失。

以配置文件運(yùn)行 deployment：

kubectl create -f nginx-git.yml

訪問(wèn) Pod 查看效果：

更實(shí)用的場(chǎng)景是將 Pod 作為 Service 暴露，通過(guò) Service 來(lái)進(jìn)行訪問(wèn)，因?yàn)楸疚闹饕v Pod，不想引入 Service 的概念。所以我們直接來(lái)訪問(wèn) Pod。

查看 Pod 對(duì)應(yīng)的 IP （也可在 Pod 詳細(xì)描述中獲得）

kubectl get -o template pod/$POD_NAME --template={{.status.podIP}}

進(jìn)入 K8S 集群，訪問(wèn) Pod 中 nginx 服務(wù)

因?yàn)楂@得 Pod IP 是 K8S 集群內(nèi)部創(chuàng)建的，外面是無(wú)法與其通信的。所以我們需要通過(guò)命令 minikube ssh 進(jìn)入集群，才可進(jìn)行 Pod 訪問(wèn)。

再把 git 倉(cāng)庫(kù)上的 index.html 內(nèi)容改為 hello world 2!，再訪問(wèn)一下 Pod 觀察結(jié)果（需等待幾秒）。

最后，我們來(lái)看下 Pod 的 IP 是如何生成的，以及內(nèi)部容器是如何關(guān)聯(lián)的。

通過(guò) docker ps 我們發(fā)現(xiàn)，nginx-git 最終會(huì)生成三個(gè)容器，分別是 git-sync, nginx, pause。

通過(guò) docker inspect $CONTAINER_ID 我們發(fā)現(xiàn)，git-sync 與 nginx 的網(wǎng)絡(luò)模型都是使用了同一個(gè)容器ID的網(wǎng)絡(luò)，而該容器ID 正好對(duì)應(yīng)了 pause 這個(gè)容器。

我們?cè)倏?pause 容器的網(wǎng)絡(luò)模型，發(fā)現(xiàn)它使用的是 bridge 模式，而分配的 IP 正是對(duì)應(yīng)了 Pod 的 IP。由此可知，Pod 內(nèi)所有容器都是通過(guò) pause 的網(wǎng)絡(luò)進(jìn)行通信的。

docker 中默認(rèn)的網(wǎng)絡(luò)模式就是 Bridge 模式。

上面演示已經(jīng)證明了集群間通過(guò) Pod IP 是可以訪問(wèn)到容器內(nèi)的服務(wù)的。我們下面證明，Pod 內(nèi)容器之間通過(guò) localhost 進(jìn)行互相訪問(wèn)。

我們進(jìn)入 git-sync 容器，通過(guò)訪問(wèn) localhost 的 80 端口，看是否能訪問(wèn)到 nginx 容器。

答案很明顯了！

本文沒(méi)有按部就班的去一一介紹 Pod 的相關(guān)功能點(diǎn)，而是通過(guò) K8S 的本地搭建，從 Pod 的基本使用開(kāi)始，通過(guò)幾個(gè)問(wèn)題穿插著介紹了 Pod 的一些主要的概念與使用。

本文知識(shí)點(diǎn)總結(jié)：

minikube 的啟動(dòng)與連接

kubectl 的使用

Pod 的命令式與配置文件的啟動(dòng)

Pod 的查看方式（概況與詳情）

Pod 生命周期中的各個(gè)狀態(tài)

deployment 對(duì) Pod 的管理

deployment, replicaset, pod 三者的關(guān)系

Pod 內(nèi)多容器的場(chǎng)景

Pod 的共享數(shù)據(jù)的臨時(shí)存儲(chǔ)與文件掛載的持久存儲(chǔ)

Pod 中 pause 的作用及網(wǎng)絡(luò)通信的原理

可能關(guān)于 Pod 的有些知識(shí)點(diǎn)沒(méi)有講到，或者有講的不對(duì)的地方，也歡迎提出和指正！

后面，也會(huì)去講關(guān)于 service，configMap，update，rollout 相關(guān)的一些內(nèi)容，希望對(duì)您有幫助~