本文介紹構建高可用Kubernetes集群的推薦配置。

類型	說明	高可靠配置建議
集群控制節點	云容器引擎專有版有控制節點，可參考如下建議提升集群整體穩定性和可靠性。	集群Master節點多可用區 、集群網絡選擇服務轉發模式、關注配額限制、監控控制節點指標
集群工作節點	一般業務應用容器運行在Kubernetes集群工作節點，可參考如下建議實現控制節點的可擴展性及可修復性，及時關注核心組件的運行狀態。	運行npd 配置DNS緩存、合理部署CoreDNS
應用層面	為確保業務應用在流量高峰期不間斷正常提供服務，可參考如下建議部署和配置應用，使應用具備彈性，并及時關注應用運行狀態提前發現潛在問題。	運行多個實例 設置資源配額、應用多可用區部署、自動彈性伸縮、日志監控告警

集群Master節點多可用區

天翼云每個區域（Region）下有不同的可用區（Availability Zone，AZ）。可用區由一個或多個數據中心組成，具備獨立的風火水電。區域的多個AZ間通過高速光纖相連，用戶可基于此構建跨AZ高可用系統。

創建集群時，部署模式選擇多可用區部署，選擇控制節點數為3或以上。多可用區部署模式下，控制節點會盡量分布在不同可用區以增強容災能力 。

集群網絡選擇

云容器引擎支持calico IPIP隧道網絡和cubecni VPC網絡。不同網絡插件存在性能和功能差異，請根據業務需求合理選擇，詳見集群網絡概述。

• VPC選擇：由于VPC間相互隔離，如果容器應用需訪問RDS數據庫等云服務實例，建議把這些云服務實例創建在同一VPC。對于已創建好處于不同VPC的云服務實例，可以通過對等連接配置兩VPC互通。
• 容器網段選擇：容器網絡網段大小直接影響可創建的節點和Pod數，所以不能設置太小。使用calico IPIP隧道網絡的集群，如果容器網段掩碼是/16，這有256*256個地址，默認情況下每個節點從容器網段一次分配的IP網段為24，此時可創建節點數為256。使用cubecni VPC網絡的集群，容器網段為VPC子網，容器網段被節點共享，每個節點會預申請10個子網IP。容器網段大小與節點數無直接關系，但影響可創建Pod數。若子網掩碼是/19，則有8192個子網地址供Pod使用。
• 服務網段選擇：服務網段決定集群中Service數上限，請根據實際需求配置Service網段。由于Service網段創建后無法修改，請勿設置過小的Service網段。

詳見集群網絡地址段規劃實踐。

服務轉發模式

Kubernetes集群的kube-proxy組件，負責Service與后端Pod間的負載均衡轉發，該組件有兩種服務轉發模式：

1. iptables：適用于Service數量較少或客戶端會出現大量并發短連接場景。當Service數超過1000時，iptables模式可能引入部分網絡延遲；
2. IPVS：相比iptables模式，其吞吐更高速度更快，適用于集群規模較大或Service數較多的場景。

關注配額限制

云服務和集群資源均有配額限制，以防止意外過度使用資源。

云服務配額：如彈性云服務器、云硬盤、虛擬私有云、彈性負載均衡、容器鏡像服務等均有配額限制，當資源配額限制無法滿足使用時，可以提交工單申請擴大配額；

集群配額：租戶可創建集群數量、單集群管理節點數量、單節點最大Pod數有配額限制，詳見使用限制。

監控控制節點指標

采集控制節點指標可以深入了解控制節點性能并提前識別問題，運行狀況不佳的控制節點會影響應用可靠性。

云容器引擎通過ccse-monitor插件對接應用性能監控服務APM，以采集集群指標，默認會采集kube-apiserver、kube-controller、kube-scheduler、etcd等核心組件指標。

可在云容器引擎控制臺的“運維管理-監控”側查看這些系統組件的監控面板。

運行npd

工作節點故障可能影響容器應用的正常運行。npd（node problem detector）是Kubernetes社區提供的用于檢測集群節點異常的插件，借助npd可及時獲取節點可能存在的異常并處理。npd插件支持自定義配置，如目標節點、觸發閾值、檢查周期等。

配置DNS緩存

CoreDNS默認不緩存DNS，當集群內DNS請求量增加時，CoreDNS可能出現如下問題：

• 延遲增加：CoreDNS要處理更多請求，DNS查詢可能變慢，從而影響業務性能；
• 資源占用率增加：CoreDNS需要占用更多CPU和內存，以滿足激增的DNS請求。

可在集群中部署NodeLocal DNSCache插件以減少DNS請求延遲，提升服務發現的穩定性和性能。該插件在每個集群節點上運行DNS緩存代理，所有注入DNS配置的Pod優先使用該DNS緩存代理進行域名解析，以減少CoreDNS服務的壓力，提高集群DNS性能。

詳見使用NodeLocal DNSCache。

合理部署CoreDNS

建議將集群的CoreDNS實例分布在不同可用區、不同節點上，避免單節點、單可用區故障。CoreDNS所在節點應避免CPU、內存高壓力，否則會影響域名解析的QPS和響應延遲。

運行多個實例

若應用程序使用單個Pod承載，如果該Pod出現異常，則直接導致應用程序不可用。

建議使用Deployment等工作負載來部署應用，對于Deployment類型的工作負載，當Pod被刪除時，deployment控制器會自動新建一個相同配置的Pod，以確保指定數量的Pod始終運行。

在創建Deployment類型工作負載時，建議指定實例數不小于2。如果一個實例發生故障，剩余的實例仍繼續運行，若故障實例被刪除，Kubernetes會自動創建另一個Pod。

可以使用容器水平伸縮（HPA）結合節點自動伸縮根據工作負載需求自動進行伸縮。

使用容器隔離進程

容器可提供一定程度的隔離，每個容器有單獨的根文件系統、網絡棧和CPU/內存等資源限制，可一定程度避免不同容器進程間相互干擾及惡意進程攻擊和數據泄露，提高應用程序的可靠性、安全性和可移植性。

可在同一個Pod內創建多個容器，以便這些容器進程需協同工作。Pod內容器可以共享相同的網絡棧、存儲卷、IPC等資源。

Pod的init容器在非init容器啟動前運行，常用于完成一些初始化任務，比如配置環境變量、準備數據存儲等等。

Pod內多個容器共享同個Pod的生命周期，例如其中一個容器無法啟動，則導致整個Pod無法進入Running狀態。

設置資源配額

建議為所有工作負載配置資源請求/限制，資源請求影響Kubernetes調度，資源請求和限制則聲明Pod的QoS。

若資源請求/限制沒有配置或配置不合理，則可能導致某個節點上調度了過多Pod或調度了較多消耗資源過多的Pod，使得節點負載太高，甚至產生節點OOM等異常，無法對外提供服務。

為避免這類問題，建議為每個Pod均配置資源請求（Request）及限制（Limit）。Kubernetes在部署Pod時，會結合Pod的資源請求和限制找一個具有充足空閑資源的節點部署。

Kubernetes采用靜態資源調度方式，對于節點剩余資源的計算方式如下：

節點剩余資源=節點總資源-已經分配出去的資源

• 節點剩余資源并不是實際可使用的資源，若手動運行一個很耗資源的程序，Kubernetes并不能感知到。
• 對于沒有聲明resources的Pod，當該Pod被調度到某個節點后，Kubernetes并不會在對應節點上扣掉該Pod使用的資源，這可能導致節點上調度太多Pod，所以建議為所有Pod配置resources。

應用多可用區部署

建議在多個不同可用區的節點上運行Pod，避免應用受到單可用區故障影響。

訂購集群時，部署模式選擇多可用區部署：

部署應用時，可為Pod設置反親和性規則，實現跨多個可用區多個節點調度Pod，詳情請參見應用高可用部署。

設置容器健康檢查

Pod內容器若異常退出，Kubernetes會自動重啟容器，能避免部分Pod容器異常導致的服務中斷。但Pod處于Running狀態并不代表Pod能正常提供服務，例如Pod內進程可能訪問RDB實例失敗且沒退出，此時Pod狀態依然是Running。建議為Pod配置存活探針（Liveness Probe），探測Pod是否存活。如果存活探針失敗超過閾值，Kubernetes會重啟Pod。

• 就緒探針（Readiness Probe）用于探測Pod是否可以正常對外提供服務。應用一般在啟動過程中需要做一些初始化動作才能對外提供服務，為Pod添加過就緒探針后，當就緒探針檢測成功時該Pod才會加入Service。當Pod的就緒探針失敗時，Pod會從對應Service移除，避免Service流量繼續轉到異常Pod。
• 啟動探針（Startup Probe）用于探測應用容器是否啟動成功。若配置了啟動探針，啟動探針成功后，Kubernetes才會進行存活探針和就緒探針檢查。建議對于啟動慢的容器配置啟動探針，避免這類Pod在啟動運行之前因存活探針失敗就被終止。

工作負載配置探針的YAML示例如下：

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: probe-demo
  name: probe-demo
spec:
  containers:
  - name: probe-demo
    image: nginx:alpine
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 10
    readinessProbe:
      exec:
        command:
          - cat
          - /tmp/healthy
      initialDelaySeconds: 10
      periodSeconds: 10
    startupProbe:
      httpGet:
        path: /healthz
        port: 80
      failureThreshold: 3
      periodSeconds: 10

自動彈性伸縮

云容器引擎的自動彈性伸縮功能提供自動調整工作負載實例數和集群節點數的能力，實現在業務高峰時快速擴容，在低谷時進行縮容，以節約資源與成本。

可配置如下兩類彈性伸縮：

• 工作負載伸縮：調整容器的資源申請/限制值可實現工作負載縱向伸縮，但這種調整會使得關聯Pod均重建，且存在瓶頸，例如節點剩余可用資源。對于無狀態應用，可通過調整Deployment的實例數實現水平伸縮，分攤每個應用實例的壓力，詳見容器水平伸縮。
• 節點伸縮：隨著Pod數不斷增加，節點剩余資源會成為瓶頸，導致無法繼續啟動新建的Pod。為解決節點資源不足問題，可以基于節點資源使用率伸縮節點數，詳見節點自動伸縮。

日志監控告警

• 日志
  • Kubernetes組件日志：kube-apiserver、kube-controller-manager、kube-scheduler、kube-proxy和kubelet等系統組件日志，可登錄集群使用kubectl命令或在云容器引擎控制臺查看，詳見查看容器實例日志 。
  • 應用日志：通過安裝ctg-log-operator插件，云容器引擎可以對接云日志服務進行容器日志采集、存儲、檢索等。
• 監控
  • Kubernetes組件監控：系統組件指標監控有助于發現問題或風險。
  • 應用指標：除了采集Kubernetes組件指標外，應用容器也可上報符合規范的自定義指標，實現應用程序的可觀測性。
• 告警
  基于監控組件采集的指標，可以配置告警規則風險預警或問題告警，詳見應用性能監控APM設置告警規則。