2.4 部署

Kubernetes中的部署是指如何控制一組Pod的運行狀態使其滿足生產需要。部署分為無狀態部署和有狀態部署。無論哪種部署，其內部都有副本集控制功能。首先了解ReplicaSet是如何控制副本數量的。

2.4.1 ReplicaSet

ReplicaSet的目的是維護一組狀態穩定的Pod副本，從而保證指定數量的相同Pod的可用性。它主要通過以下聲明來控制副本數量：

之前曾有ReplicationController，后來逐漸被ReplicaSet替代。

ReplicaSet聲明文件中，需要Pod模板以進行復制，同時也需要標簽選擇器.spec.selector.matchLabels以選擇當前Pod的副本。在nfs-provisioner的模板聲明文件中有標簽為app:nfs-provisioner的選擇器，部分代碼如下：

請注意，.spec.template.metadata.labels必須和.spec.selector.matchLabels匹配，否則無法創建ReplicaSet。

在Pod運行過程中，也可以通過kubectl scale命令手動調整副本數量：

也可以自動調整ReplicaSet的副本數量，下面的命令是對foo這個ReplicaSet Controller設置自動調整規則——最多5個副本，而且在CPU使用率達到80%的時候需要增加副本。

在Kubernetes中，自動分配副本數量的算法如下：

例如當前副本數量是2，CPU度量值為200MHz，期望度量值為100MHz，則應當的副本數量為200/100=2。如果當前CPU度量值為300MHz，而期望度量值為200MHz，則應當的副本數量為300/200=1.5，進位取整后為2。所以不需要調整副本數量。

除了通過命令來控制Pod副本數量，還可以通過聲明文件來控制，其類型為HorizontalPodAutoscaler。以下聲明和命令的效果是一致的。

請注意，自動調整Pod副本數量的依據是度量值。在上面的例子中是通過CPU的averageUtilization來進行判斷的，也可以根據Value、AverageValue、requests-per-second、packets-per-second等度量值來進行判斷。

Kubernetes從1.8版本開始使用額外的工具Metrics Server（https://github.com/kubernetes-incubator/metrics-server）收集度量指標，因此需要單獨安裝Metrics Server。安裝完成后，若出現無法收集指標的故障，則需要修改metrics-server-depolyment.yaml文件，添加args參數，然后重新應用該文件。修改部分代碼如下：

2.4.2 部署

部署（Deployment）是一個擁有ReplicaSet并通過聲明來控制Pod滾動、更新的對象。雖然ReplicaSet可以獨立使用，但是它主要被用作協調Pod創建、刪除和更新的機制。使用部署時，用戶不必擔心副本集，因為部署通過ReplicaSet進行管理，所以，本書建議使用部署而不是ReplicaSet。

下面是一個部署的聲明文件，部署了3個nginx的Pod副本：

這個例子與ReplicaSet的示例是一樣的，這是因為部署通過ReplicaSet來控制副本數量。但是如何更新副本數量，則是部署的職責，其通過StrategyType、RollingUpdateStrategy等屬性來控制如何更新Pod副本。

.spec.strategy.type的可選值有重建（Recreate）和滾動更新（RollingUpdate）。Recreate是指重建所有Pod，其過程為先終止Pod所有的副本，然后重新創建指定數量的Pod副本。而RollingUpdate則采取一定的控制策略來逐步更新Pod副本。

.spec.strategy.rollingUpdate.maxUnavailable是一個可選字段，是指更新過程中最大不可用的Pod數量。該值可以是絕對數值，也可以是百分比。其默認值為25%。例如，如果該值為25%，則原有部署中的ReplicaSet立刻將副本數量縮減為75%，然后準備新的Pod副本，再繼續控制25%的不可用的比例，逐步縮減原有Pod副本，直至所有Pod更新完成。

.spec.strategy.rollingUpdate.maxSurge也是一個可選字段。它指定了Pod副本的最大副本數量。例如取默認值為25%，則在更新部署時可創建的Pod副本數量是期望副本數量的125%。

.spec.minReadySeconds是一個可選字段，默認為0。它指明新創建的Pod在沒有任何容器崩潰的情況下到內部應用所需的時間。例如作者所在學校部署Apereo CAS時，在Pod創建完成并running狀態下，CAS啟動正常還需要約1min，則需設置.spec.minReadySeconds=60。

下面是影響升級過程的幾個重要參數：

（1）新的ReplicaSet創建maxSurge所指定數量的Pod副本，此時新舊Pod副本數量為期望副本數量和maxSurge個副本數量之和。

（2）在創建新的Pod副本時，馬上從舊的ReplicaSet中刪除maxUnavailable個Pod。這時可用Pod副本數量為期望副本數量減去maxUnavailable。

（3）當新創建的Pod副本有一個可用時，馬上從舊的ReplicaSet中刪除一個Pod，如此反復直至所有舊的Pod被新的Pod替換。

這就要求maxUnavailable和maxSurge不能同時為0。

如果在版本升級過程中又觸發了更新的版本升級，則Kubernetes會暫停之前版本的替換過程，用最新的版本替換之前剛剛升級的版本，然后再用最新的版本替換還未升級的版本。

部署可以回滾到以前的版本，也支持擴展和自動擴展。

2.4.3 有狀態部署

有狀態部署（StatefulSets）是用于管理有狀態應用程序工作負載的一種部署方法。區別于無狀態部署（Deployment），StatefulSets可以對Pod副本進行排序并保證每個Pod的唯一性。在無狀態部署中，刪除一個Pod，新建一個Pod，對于所有Pod來講都是一致的。但是在StatefulSets中，每個Pod都有唯一的持久標識符，即使在重建后也會繼續保留該標識符。

有狀態部署適合以下場景：

● 需要獨特的網絡標識符。

● 需要獨立持久的存儲。

● 需要有序的部署和擴展。

● 需要有序的升級。

下面演示創建一個nginx的StatefulSet部署。主要內容有：

● 名稱為nginx的無頭服務。

● 名稱為web的StatefulSet。

以上聲明文件與無狀態部署（Deployment）一致，只是系統在創建后的Pod標識符是唯一且有序數的。

通過kubebctl get pods命令查看，可以看到每個Pod的名稱為web-<序數>，而不是web-<隨機字符串>。這樣，每個Pod也都有自己獨立易記且固定的主機名稱，例如web-0，其FQDN為web-0.nginx.default.svc.cluster.local。

每個Pod的存儲卷也是特定的，不能混用。而且刪除Pod時，為了保留該狀態，持久卷不會自動刪除。

在StatefulSet中Pod的部署過程與無狀態部署完全不同。在無狀態部署中，Pod副本并發創建，而在有狀態部署中，Pod是依次順序創建。在上例中，web-0、web-1和web-2是依次創建，而且web-1是在web-0創建完成并且正常運行后再創建。如果要刪除部署，則順序恰好相反，最晚創建的容器被最早刪除。

2.4.4 DaemonSet

一個DaemonSet確保每個節點上只運行一個副本。若有節點添加到集群中，將在新增的節點上運行唯一一個Pod，若節點刪除，則從該節點上終止Pod。

DaemonSet適合以下場景：

● 每個節點上運行集群存儲后臺駐留程序，例如glusterd、ceph。

● 每個節點上運行日志守護程序，例如fluentd、logstash。

● 每個節點上運行Prometheus node exporter、sisdig、collectd等代理。

DaemonSet的示例在此不再詳述，在講解日志和監控時會詳細描述DaemonSet。