Kubernetes核心概念
要深入的理解Kubernetes的特性和工作機制，首先要掌握Kubernetes模型中的核心概念。從集群組件的角度來看，Kubernetes主要是主節(jié)點中的組件，如kube-apiserver、kube-scheduler等，工作節(jié)點中的組件，如kubelete、kube-proxy、Docker等；從資源抽象的角度來看，主要就是幾個抽象的概念，如容器組(Pod)、復制控制器(Replication Controller，RC)、部署(Deployment)和服務(wù)(Service)等。
Kubernetes 集群組件
Master組件
- kube-apiserver：集群核心，API接口、集群各個組件通信的中樞；集群安全控制；
- kube-scheduler：集群Pod的調(diào)度中心；
- kube-controller-manager：集群狀態(tài)管理器，當集群狀態(tài)與期望不同時，KCM會努力讓集群恢復期望狀態(tài)，例如：當一個Pod死掉，KCM會努力新建一個Pod來恢復對應(yīng)replicas set期望的狀態(tài)；
- etcd：集群的數(shù)據(jù)中心；
Node組件
- kubelet：負責與節(jié)點上的Docker守護進程通信；
- kube-proxy: 實現(xiàn)了Service的代理以及軟件模式的負載均衡，主要是為節(jié)點間的通信進行服務(wù)；每個節(jié)點上都運行一個kube-proxy進程，kube-proxy負責將到某個service的請求轉(zhuǎn)發(fā)到具體的Pod上。
- Docker：運行Docker容器；
Kubernetes 資源抽象
Kubernetes對集群中的資源進行了不同級別的抽象，如容器組(Pod)、復制控制器(Replication Controller，RC)、部署(Deployment)和服務(wù)(Service)等。每個資源都是一個REST對象，通過API進行操作，通過JSON或者YAML格式的模板文件進行定義。
容器組 Pod
Kubernetes并不直接操作容器，它的最小管理單位是容器組（Pod）。Pod由一個或者多個容器組成，Kubernetes圍繞Pod進行創(chuàng)建、調(diào)度、停止等生命周期管理。
同一個Pod中的容器之間共享命名空間、CGROUPS限制和存儲卷。這就意味著同一個Pod中的容器之間可以方便的通信?？梢詫od想象成一個“虛擬機”，而Pod中的容器就是虛擬機中運行的進程。
通常位于同一個Pod中的容器之間有比較緊密的關(guān)系，如：一個Pod中部署web應(yīng)用、日期采集應(yīng)用、狀態(tài)監(jiān)控應(yīng)用。
Kubernetes中每個資源都是一個REST對象，用戶可以通過YAML或者JSON模板來定義一個Pod資源，例如：
apiVersion: v1
kind: pod
metadata:
name: nginx-text
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
YMAL文件的格式：① 冒號之后必須要有空格；② 縮進是兩個空格；③ - 代表列表或者數(shù)組；
復制控制器 (Replication Controller，RC）
復制控制器類似一個監(jiān)控進程，負責在Pod出現(xiàn)故障時，重新生成一個Pod。RC就是為了Pod的高可用而設(shè)計的。
用戶申請Pod之后，復制控制器RC負責將Pod調(diào)度到某個節(jié)點上，并保證它的給定份數(shù)(replica)正常運行。當實際運行的Pod份數(shù)超過數(shù)目，則終止一些Pod；當不足，則創(chuàng)建新的Pod。一般建議即使Pod的份數(shù)為1，也要是用復制控制器RC來創(chuàng)建，而不是直接創(chuàng)建Pod。
ReplicaSet是新一代的RC，ReplicaSet和RC的唯一區(qū)別就是二者對選擇器的支持不同，RC僅僅支持 equality-based selector而ReplicaSet支持set-based selector。
部署 Deployment
Deployment為Pod和Replica Set（下一代Replication Controller）提供聲明式更新。
你只需要在Deployment中描述你想要的目標狀態(tài)是什么，Deployment controller就會幫你將Pod和Replica Set的實際狀態(tài)改變到你的目標狀態(tài)。你可以定義一個全新的Deployment，也可以創(chuàng)建一個新的替換舊的Deployment。
一個典型的用例如下：
- 使用Deployment來創(chuàng)建ReplicaSet。ReplicaSet在后臺創(chuàng)建pod。檢查啟動狀態(tài)，看它是成功還是失敗。
- 然后，通過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態(tài)。這會創(chuàng)建一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中。
- 如果當前狀態(tài)不穩(wěn)定，回滾到之前的Deployment revision。每次回滾都會更新Deployment的revision。
- 擴容Deployment以滿足更高的負載。
- 暫停Deployment來應(yīng)用PodTemplateSpec的多個修復，然后恢復上線。
- 根據(jù)Deployment 的狀態(tài)判斷上線是否hang住了。
- 清除舊的不必要的ReplicaSet。
服務(wù) Services
RC、RS和Deployment只是保證了支撐服務(wù)的微服務(wù)Pod的數(shù)量，但是沒有解決如何訪問這些服務(wù)的問題。
Kubernetes中服務(wù)的提出主要是解決Pod地址可變的問題。由于Pod隨時可能出現(xiàn)故障，并可能在其他節(jié)點上被重啟，Pod地址是不能保持固定的。因此，用一個服務(wù)來代表提供某一類功能的一些Pod，并分配不隨Pod位置變化而改變的虛擬訪問地址(Cluster IP)。
如下圖service中包含兩個Pod，一個Pod位于一臺主機上，每個Pod中上運行一個MySQL服務(wù)的容器，用戶是直接通過service的cluster ip來使用MySQL服務(wù)。
同其他資源類似，服務(wù)資源的JSON格式定義如下：
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "web-service",
},
"spec": {
"selector": {
"app": "webApp"
},
"ports": [
{
"protocol": "TCP",
"port": 80,
"targetPort": 80,
}
]
}
}
從上述分析可知，Pod具有臨時性，隨時都可能出現(xiàn)故障，因此通過Pod自身的地址訪問應(yīng)用是不可靠的，而需要通過服務(wù)訪問，Service、Pod、RC和Namespace之間的關(guān)系如下圖所示：
【持續(xù)改進和更新中】
