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

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

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

Mac OS 10.11.x

kubectl == v1.6.4

minikube == v0.19.1

docker == 1.11.1

使用 minikube 本地搭建 K8S

證明每個 Pod 都有一個 Pause

Pod 的基本使用

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

Pod 的管理問題

Pod 的多容器場景

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

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

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

啟動 minikube（minikube 是一個能讓 K8S 本地運行的工具）

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 會在你的電腦上安裝一個 VirtualBox 的虛擬驅(qū)動。因為 docker 支持的只有 Linux 系統(tǒng)，為了讓它能在 Mac 上運行，實際上是運行由 VirtualBox 運行的虛擬環(huán)境下的。--vm-driver 默認(rèn)的參數(shù)也是 VirtualBox。再來看 xhyve，它實際和 VirtualBox 類似，簡單理解，它是一個更輕量的虛擬技術(shù)。

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

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

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

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

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

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

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

kubectl get pods --all-namespaces

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

驗證每個 Pod 內(nèi)都會運行一個 Pause 容器

docker ps

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

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

kubectl run nginx --image=nginx

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

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

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

kubectl get deploy

查看 Pod 列表

kubectl get pods

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

kubectl describe pod $POD_NAME

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

下面常見的有這幾種：

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

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

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

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

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

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

kubectl get rs

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

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

驗證：當(dāng)手動刪除 Pod 時，Deployment 會自動創(chuàng)建一個新的 Pod，來確保與期望值的匹配。

kubectl delete pod $POD_NAME

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

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

kubectl delete deploy $DEPLOY_NAME

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

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

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

這里通過配置文件來啟動包含 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 # 啟動 nginx 容器
        image: nginx
        volumeMounts: # 掛載數(shù)據(jù)卷
        - mountPath: /usr/share/nginx/html
          name: git-volume
      - name: git-sync # 啟動 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)該比較容易理解，這里簡單講下兩點：

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

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

臨時存儲：

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

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

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

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

注意：即使是臨時存儲，因為數(shù)據(jù)是 Pod 下所有容器共享的，任何一個容器重啟，數(shù)據(jù)都不會丟失。當(dāng) Pod 結(jié)束時，臨時性數(shù)據(jù)才會丟失。

以配置文件運行 deployment：

kubectl create -f nginx-git.yml

訪問 Pod 查看效果：

更實用的場景是將 Pod 作為 Service 暴露，通過 Service 來進(jìn)行訪問，因為本文主要講 Pod，不想引入 Service 的概念。所以我們直接來訪問 Pod。

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

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

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

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

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

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

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

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

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

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

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

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

答案很明顯了！

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

本文知識點總結(jié)：

minikube 的啟動與連接

kubectl 的使用

Pod 的命令式與配置文件的啟動

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

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

deployment 對 Pod 的管理

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

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

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

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

可能關(guān)于 Pod 的有些知識點沒有講到，或者有講的不對的地方，也歡迎提出和指正！

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