（第8章）一切皆容器：Kubernetes

1.Kubernetes是啥？

• Kubernetes是一個管理跨主機容器化應用的系統，實現了包括應用部署、高可用和彈性伸縮哎內的一系列基礎功能並封裝稱爲一整套完整、簡單易用的restful api對外提供服務。

• K8S建立了一套健壯的集羣自恢復機制，包括：容器的自動重啓、自動重調度及自動備份

• K8S的服務對象是：由多個容器組合而成的複雜應用，如：彈性、分佈式的服務架構。
  K8S引入了專門對容器進行分組管理的pod，K8S對外提供容器服務的模式是：用戶提交容器集羣運行所需要的資源的申請(就是個配置文件)，然後由K8S負責完成這些容器的調度任務(就是自動地爲這些容器選擇運行的宿主機)

2.K8S集羣部署Guestbook應用例子

• eg：應用部署說明如下：
  （1）它是一個PHP網站，同時運行3個副本來保證高可用
  （2）該PHP網站在Redis裏存儲了一個數據，不定期進行讀寫
  （3）該Redis服務由1個Master節點和2個slave節點組成的高可用集羣，讀請求由Slave處理，寫請求則交給Master
  （4）使用負載均衡組件來完成多個Redis Slave之間以及PHP實例之間的請求分配
  在K8S中部署如下：
  php的副本數量爲3，Redis Slave的數量爲2，Redis Master的副本數量爲1
  

（1）用戶在創建容器時，會給每個容器指定一個用來分組的標籤label：比如所有的php網站容器都屬於name=frontend

（2）這些容器可以使用IP：PORT的方式進行通信，但是K8S內置了service代理組件，可以使用固定的IP，以防止容器重啓

（3）replication controller，label和service，真正操作的對象都是一個稱之爲pod的邏輯對象。並通過APIServer組件提供了
一套對它們按照RESTful格式的增刪改查和監聽接口。

3.pod

• 在K8S中，能夠被創建、調度和管理的最小單元是pod

• pod可以想象成一個籃子，而容器則是籃子裏的雞蛋，
  當K9S需要調度容器時，它直接把一個籃子(連同裏面的雞蛋)從一個宿主機調度到另一個宿主機。
  其關係包括：
  （1）一個pod裏的容器能有多少資源取決於這個籃子的大小；
  （2）label也是貼在籃子上的；
  （3）IP分配給籃子而不是容器，籃子裏面的所有容器共享這個IP；
  （4）哪怕只有一個雞蛋(容器)，K8S仍然會給他分配一個籃子；

• pod容器共享的內容，包括：
  （1）IP及對應的network namespace是由pod裏的容器所共享的
  （2）pod內的所有容器共享volume
  （3）同一個pod內的應用容器能夠使用System VIPC或者POSIX消息隊列進行通信
  （4）同一個pod內的應用容器共享主機名

• label和label selector與pod協作
  （1）labels屬性是一組綁定到K8S對象(eg:pod)上的鍵值對，同一個對象labels屬性的key必須獨一無二。
  一個label的key：代表一個資源管理維度(eg:release，environment)
  
  （2）label selector作爲發送給APIServer的RESTful查詢請求的條件參數，用於檢索一個與label selector匹配的K8S對象列表

查詢方法：
（1）基於值相等的查詢條件
environment=production,tier!=frontend
表示的意思：過濾出爲域production環境，但是非前端的資源對象

（2）基於子集的查詢條件
key值=enviroment，且value值=production或qa的資源對象
enviroment in (production, qa)

選擇key值=tire，value值!=frontend且backend的資源對象

選擇所有labels屬性中包含key值=partition的資源對象，不需要檢查value值
partion

• pod的現狀和未來走向
  （1）目前pod內的容器共享同一個network namespace，IP資源和端口區間，能夠通過localhost進行相互間的通信
  （2）pod對於K8S來說，最有用的價值就是原子化調度，即：在爲一個pod選擇目的宿主機時，K8S會考量這個機器是夠能放下整個pod，而避免出現本應該部署在一起的容器因爲資源不足，無法滿足“超親密”關係

• pod的使用場景
  儘量不要在單個pod中運行同一個應用的多個實例

• pod使用實例

（1）創建K8S對象
kubectl creat -f obj.json
obj.json可以是定義pod，replication controller，service等K8S對象的json格式的資源配置文件

（2）將配置內容寫入testpod.json文件
kubectl creat -f testpod.json
注意：同一個pod內的容器端口不能重複；同一個pod的不同容器的端口不要映射到宿主機的同一個端口；

（3）查看pod信息
kubectl get pod

（4）查看pod中master1容器輸出的log信息
kubectl log podtest master1

• pod內的容器網絡與通信
  假設pod內一共有3個容器
  
  上面兩個是用戶容器，第三個是K8S的網絡容器

（1）容器master1將6379端口映射到宿主機的6388端口；
將master2容器的22端口映射到宿主機上的8888端口；

（2）先通過ssh的方式進入master2容器
ssh root@127.0.0.1 -p 8888

在master2容器內通過localhost訪問master1容器
telnet 127.0.0.1 6379

4.replication controller設計

• K8S決定了一個pod有多少同時運行的副本，並保證這些副本的期望狀態與當前狀態一致。
• 任何時候一個pod中的容器退出或者整個pod變成Failed，replication controller都會固執地重啓這個容器或者pod
• replication controller的描述文件，包括：
  創建pod的pod模板（pod template），一個期望副本數和一個用於選擇被控制的pod集合的label selector；
  （1）從下面的描述文件可以看出：replication controller通過使用於定義的pod模板來創建pod，一旦pod創建成功，對模板的任何更改都不會對已經在運行的pod有任何直接的影響。
  （2）刪除一個replication controller不會影響它所創建的pos，若想刪除一個replication controller所控制的pod，需要將其replicas字段設置爲0
  （3）通過修改pod的labels，可以將一個pod從replication controller的控制集中移除
  （4）如下所示：該replication controller實例化了2個運行nginx的pod，replication controller通過使用預定義的pod模板來創建pod， 一旦pod創建成功，對模板的任何更改都不會對已經在運行的pod有任何直接的影響。
  調整這些已經在運行的pod的CPU，MEM參數等操作應該直接更新pod本身而不是更新replication controller。
  （4）可以通過修改podlabels將一個pod從replicatin controller的控制集中移除，然後針對這個pod進行debug、數據恢復等操作。此外，replication controller則會自動重啓一個新的pod來替換被移除的pod
  （5）若想要刪除一個replication controller所控制的pod，需要將該replication controller的副本數(replicas)字段置爲0，這樣所有的pod都會被自動刪除。
  

5.replication controller的典型場景

• （1）重調度。