1. 架構
-
全局架構圖
![]()
-
Master節點
- kube-apiserver（負責API服務）
- kube-scheduler（負責調度）
- kub-controller-manager（負責容器編排）
集羣的持久化存儲，由kube-apiserver處理後保存在Etcd
-
計算節點
- Networking
- kubelet
- 和Container Runtime打交道，通過CRI（Container Runtime Interface）
只要是可運行的標準鏡像容器，都可以通過CRI接入到Kubernetes項目中
- 通過OCI這個容器運行時規範和底層的Linux系統交互
把CRI請求翻譯成對Linux的系統調用（操作Linux namespace和cgroups等）
- 通過gRPC協議和Device Plugin插件交互
- 通過CNI（Container Network Interface）和CSI（Container Storage Interface)，和網絡產檢和存儲插件交互來爲容器配置網絡和持久化存儲
- Container Runtime
容器運行時是什麼？
一個由Namespace + Cgroups構成的隔離環境，這部分被稱爲“容器運行時”，是容器的動態視圖。 ref：《Docker（2）容器技術基本概念理解》 - Volume Plugin
- Device Plugin
- ...(Linux OS)
2. Google項目Borg對Kubernetes項目的指導作用
kublet完全是爲了實現Kubnetes項目對容器的管理能力而重新實現的一個組件，與Borg之間並沒有直接的傳承關係。而且Borglet本身也不會對容器進行進行管理。
從一開始，Kubernetes項目就沒有向同時期的“容器雲”項目那樣，把Docker作爲整個架構的核心，而是僅僅把它作爲最底層的一個容器運行時實現。
3. Kubernetes要着重解決的問題
運行在大規模集羣之間的各個任務之間，實際上存在着各種各樣的關係。這些關係的處理，纔是作業編排和系統管理最重要的地方。如Web應用和DB之間的訪問關係、一個負載均衡器和他後端服務的代理關係，一個門戶應用與授權組件之間的調用關係。
4 Kubernetes的主要設計思想
從更加宏觀的角度，以統一的方式來定義任務之間的各種關係，並且爲將來支持更多種類的關係留有餘地。
架構設計中，如果要追求項目的普適性，就一定要從頂層開始做好設計。
- 什麼是軟件的頂層設計？
舉例
Kubernetes對容器間的訪問進行了分類
- 需要進行非常平頻繁的交互和訪問的應用，會被部署在同一臺機器上，通過Localhost通信，通過本地磁盤目錄交換文件。而在Kubernetes項目中，這些容器會被劃分爲一個Pod，Pod裏的容器共享一個Network Namespace、同一組數據卷，從而達到高效交換信息的目的。
- 就是說同一個Pod中，多個Docker容器的Network Namespace是共享的，而不是各自和外部隔離
- Pod、Master節點+計算節點 這兩者之間是怎樣的關係？
- Web應用和數據庫之間的訪問關係，Kubernetes會提供一種叫“Service”的服務。像這兩種應用往往故意不部署在同一個物理節點上，這樣即使Web應用所在機器宕機了，數據庫不會受到影響。
Service服務的主要作用：作爲Pod的代理入口（Portal），從而代理Pod對外暴露一個固定的網絡地址。作用是，解決對於一個容器來說，他的IP信息是不固定的，但是通過給Pod綁定一個Service服務作爲Pod的代理入口，就能夠固定下（數據庫）的訪問的網絡地址。而Service後端真正代理Pod的IP地址、端口等信息的自動更新、維護，則是Kubernetes項目的職責。
- 提問：
爲什麼對於一個容器來說，他的IP信息是不固定的？？
4.1 應用訪問的鑑權
Kubernetes提供了一種叫做Secret的對象存儲在Etcd中的鍵值對數據。在Kubernetes會在用戶指定的Pod啓動時，自動將Secret中的數據以Volume的方式掛載到容器（如Web應用容器）裏。這樣（Web應用）容器就可以訪問數據庫了。
4.2 應用的運行形態
除了應用之間的關係之外，應用運行的形態是影響“如何容器化這個應用”的第二個重要原因。因此，kubernetes定製了基於Pod的改造後的對象。如：
| 形態 | 場景 |
|---|---|
| Job | 描述一次性運行的Pod（如大數據任務） |
| DaemonSet | 描述每個宿主機上必須且只能運行一個副本的守護進程服務 |
| CronJob | 描述定時任務 |
| ... | ... |
4.3 聲明式API
Kubernetes並沒有像其他項目一樣，爲每個管理功能創建一個指令，然後在項目中實現其中的邏輯。這種做法的在拓展性上不好。
Kubernetes的做法是：
+ 通過一個“編排對象”，如Pod， Job，CronJob等，來描述用戶試圖管理的應用；
+ 然後，再爲他定義一些“服務對象”，比如Service， Secret， Horizaontal Pod Autoscaler(水平拓展器）等負責具體的平臺級功能。
這兩點Kubernetes的最核心的設計理念
4.4 Kubernetes項目核心功能的“全景圖”
5. Kubernetes的使用（Kubernetes如何啓動一個容器化任務）
先說怎麼用，後續博文補充細節
場景： 做好了一個Nginx容器鏡像，希望通過平臺啓動這個鏡像。並且，運行兩個完全相同的Nginx副本，以負載均衡的方式共同對外提供服務。
Step 1 編寫一個Yaml文件
nginx-deployment.yaml(核心是spec.template部分)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
Step 2 執行
$ kubectl create -f nginx-deployment.yaml
搞定，也正是在這種“聲明式API”的基礎上，才能夠實現強大的編排能力。
編排是什麼？
過去很多集羣管理項目，比如Yarn、Mesos和Swarm所擅長的，是把一個容器，按照某種規則，放置在某個最佳節點運行起來，這種功能被叫做“調度”。
而Kubernetes做的事情是，按照用戶的意願和整個系統的規則，完全自動化地處理好容器之間的各種關係。這種功能，就是編排。所以說，Kubernetes的本質，是爲用戶提供一個具有普遍意義的容器編排工具。
更重要的是，Kubernetes項目爲用戶提供的了一套基於容器構建分佈式系統的基礎依賴。
後續的博文，會重點關注Kubernetes裏面到底是如何實現的，來加深對本文中Kubernetes架構和設計思想和理解。
思考題：
- Docker Swarm（SwarmKit項目）和Kubernetes在架構和使用方法上有什麼區別？
- 在Kubernetes之前，有很多項目都沒辦法管理“有狀態”的容器，就是說，不能從一臺宿主機“遷移”到另一臺宿主機上的容器。你是否能列舉出，組織這種遷移的原因。