ACK叢集工作負載Workload推薦配置 - Container Service for Kubernetes

在ACK叢集中配置工作負載（Deployment、StatefulSet、DaemonSet、Job、CronJob等）時，您需考慮多種因素，以確保應用可以穩定、可靠地運行。

聲明每個Pod的resource（Request和Limit）

在使用Kubernetes叢集時，經常會遇到在一個節點上調度了太多的Pod，導致節點負載過高，無法正常對外提供服務的問題。

為避免上述問題，在Kubernetes叢集中部署Pod時，您可以指定該Pod所需的Request及Limit資源，Kubernetes在部署這個Pod的時候，就會根據Pod的需求找一個具有充足空閑資源的節點部署這個Pod。下面的例子中，聲明Nginx這個Pod需要1核CPU，1024MB的記憶體，運行中實際使用不能超過2核CPU和4096MB記憶體。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resources: # 資源聲明
      requests:
        memory: "1024Mi"
        cpu: "1000m"
      limits:
        memory: "4096Mi"
        cpu: "2000m"

Kubernetes採用靜態資源調度方式，對於每個節點上的剩餘資源的計算為節點剩餘資源=節點總資源-已經分配出去的資源，並不是實際使用的資源。如果您自己手動運行一個資源消耗較大的程式，Kubernetes並不能感知到。

此外，所有Pod都要聲明resources。沒有聲明resources的Pod被調度到某個節點後，Kubernetes不會在對應節點上減去這個Pod使用的資源，繼而可能導致該節點上被調度過多Pod。

您可以使用ACK提供的資源畫像功能，基於資源使用量的歷史資料獲得容器粒度的資源規格推薦，簡化為容器配置Request和Limit的複雜度。更多資訊，請參見資源畫像。

啟動時等待下遊服務，不要直接退出

有些應用可能會有一些外部依賴，例如需要從資料庫（DB）讀取資料或者依賴另外一個服務的介面。應用啟動時，外部依賴未必都能滿足。手動營運時，通常採用依賴不滿足立即退出的方式，也就是所謂的failfast，但在Kubernetes中，這種策略不再適用。這是因為Kubernetes中多數營運操作都是自動操作，無需人工介入。例如，部署應用時，無需自己選擇節點，再到節點上啟動應用；應用fail時，也無需手動重啟，Kubernetes會自動重啟應用；負載增高時，還可以通過HPA自動擴容。

啟動時依賴不滿足的情境下，可以假設有兩個應用A和B，A依賴B且運行在同一個節點上，此節點因為某些原因重啟，重啟後，A首先啟動，B還沒啟動，對於A來說就是依賴不滿足。如果A還是按照傳統的方式直接退出，當B啟動之後，A也不會再啟動，必須人工介入處理。

在Kubernetes叢集中，推薦您啟動時檢查依賴，如果不滿足，則進行輪詢等待，而不是直接退出。可以通過 Init Container完成這個功能。

配置restart policy

Pod運行過程中進程退出十分常見。代碼中存在Bug、佔用記憶體太多等，都會導致應用進程退出，繼而導致Pod退出。您可在Pod上配置restartPolicy，實現Pod退出後自動啟動。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    restartPolicy: OnFailure

restartPolicy有三個可選值：

Always：總是自動重啟。
OnFailure：異常退出時自動重啟（進程退出狀態非0）。
Never：從不重啟。

配置Liveness Probe和Readiness Probe

Pod處於Running狀態和Pod能正常提供服務是完全不同的概念。一個Running狀態的Pod，裡面的進程可能發生了死結而無法提供服務。但是因為Pod還是Running的，Kubernetes也不會自動重啟這個Pod。所以我們要在所有Pod上配置Liveness Probe，探測Pod是否真的存活，是否還能提供服務。如果Liveness Probe發現了問題，Kubernetes會重啟Pod。

Readiness Probe用於探測Pod是否可以對外提供服務。應用啟動過程中需要一些時間完成初始化，在這個過程中是無法對外提供服務的，通過Readiness Probe，可以告訴Ingress或者Service是否可以將流量轉寄到這個Pod上。當Pod出現問題時，Readiness Probe可以避免新流量繼續轉寄到這個Pod。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    livenessProbe:
      httpGet:
        path: /index.jsp
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /index.jsp
        port: 8080

每個進程一個容器

很多剛剛接觸容器的人喜歡按照舊習慣把容器當作虛擬機器（VM）使用，在一個容器裡放置多個進程：監控進程、日誌進程、sshd進程，甚至整個Systemd。這樣操作存在兩個問題：

判斷Pod整體的資源佔用會變複雜，不方便實施Pod Resource涉及到的Request和Limit。
容器內只有一個進程的情況下，如果進程中斷，外部的容器引擎可以清楚地感知到，並且重啟容器。如果容器內有多個進程，某個進程掛了，容器未必受影響，外部的容器引擎無法感知到容器內有進程退出，也不會對容器做任何操作，但是實際上容器已經不能正常工作了。

如果有幾個進程需要協同工作，在Kubernetes裡也可以實現，例如：nginx和php-fpm，通過Unix domain socket通訊，我們可以用一個包含兩個容器的Pod，將Unix socket放在兩個容器的共用Volume中。

確保不存在SPOF（Single Point of Failure）

如果應用只有一個執行個體，當執行個體失敗的時候，雖然Kubernetes能夠重啟執行個體，但是中間不可避免地存在一段時間的不可用。甚至更新應用，發布一個新版本的時候，也會出現這種情況。在Kubernetes裡，盡量避免直接使用Pod，儘可能使用Deployment/StatefulSet，並且讓應用的Pod在兩個以上。

Container Service for Kubernetes：工作負載推薦配置