叢集服務

叢集服務會在 EKS 叢集內執行，但不是使用者工作負載。如果您有 Linux 伺服器，通常需要執行 NTP、syslog 和容器執行時間等服務來支援工作負載。叢集服務類似，支援服務可協助您自動化和操作叢集。在 Kubernetes 中，這些通常會在 kube-system 命名空間中執行，有些會以 DaemonSets 的形式執行。

叢集服務預期具有較高的運作時間，通常在中斷和故障診斷期間至關重要。如果核心叢集服務無法使用，您可能會無法存取可協助復原或防止中斷的資料 （例如高磁碟使用率）。它們應該在專用運算執行個體上執行，例如單獨的節點群組或 AWS Fargate。這將確保叢集服務不會受到可能擴展或使用更多資源的工作負載對共用執行個體的影響。

擴展 CoreDNS

擴展 CoreDNS 有兩個主要機制。減少對 CoreDNS 服務的呼叫數量，並增加複本數量。

透過降低點陣來減少外部查詢

ndots 設定指定網域名稱中有多少句點 (a.k.a. "dots") 被視為足以避免查詢 DNS。如果您的應用程式有 5 （預設） 的 ndots 設定，而且您向 api.example.com (2 個點） 等外部網域請求資源，則會針對 /etc/resolv.conf 中為更特定網域定義的每個搜尋網域查詢 CoreDNS。根據預設，在提出外部請求之前，將搜尋下列網域。

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

namespace 和 region值將取代為您的工作負載命名空間和運算區域。根據您的叢集設定，您可能還有其他搜尋網域。

您可以降低工作負載的 ndots 選項，或包含結尾 （例如 api.example.com. ) 來完全限定您的網域請求，以減少對 CoreDNS 的請求數量。如果您的工作負載透過 DNS 連線至外部服務，建議您將 ndot 設定為 2，讓工作負載不會在叢集內進行不必要的叢集 DNS 查詢。如果工作負載不需要存取叢集內的服務，您可以設定不同的 DNS 伺服器和搜尋網域。

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

如果您將點降到太低的值，或您要連線的網域未包含足夠的特異性 （包括結尾 。)，則 DNS 查詢可能會失敗。請務必測試此設定將如何影響您的工作負載。

水平擴展 CoreDNS

CoreDNS 執行個體可以透過將其他複本新增至部署來擴展。建議您使用 NodeLocal DNS 或叢集比例自動擴展器來擴展 CoreDNS。

NodeLocal DNS 需要每個節點執行一個執行個體，做為 DaemonSet，這需要叢集中的更多運算資源，但可以避免 DNS 請求失敗，並減少叢集中 DNS 查詢的回應時間。叢集比例自動擴展器會根據叢集中的節點或核心數量來擴展 CoreDNS。這與請求查詢沒有直接關聯，但根據您的工作負載和叢集大小可能很有用。預設比例擴展是為叢集中的每 256 個核心或 16 個節點新增一個額外的複本，以先發生者為準。

垂直擴展 Kubernetes 指標伺服器

Kubernetes Metrics Server 支援水平和垂直擴展。透過水平擴展指標伺服器，它將具有高度可用性，但不會水平擴展以處理更多叢集指標。當節點和收集的指標新增至叢集時，您將需要根據指標伺服器的建議垂直擴展指標伺服器。

Metrics Server 會保留其在記憶體中收集、彙總和提供的資料。隨著叢集的成長，指標伺服器存放的資料量會增加。在大型叢集中，相較於預設安裝中指定的記憶體和 CPU 保留，Metrics Server 需要更多的運算資源。您可以使用 Vertical Pod Autoscaler (VPA) 或 Addon Resizer 來擴展指標伺服器。附加元件恢復器會根據工作者節點按比例垂直擴展，而 VPA 會根據 CPU 和記憶體用量擴展。

CoreDNS lameduck 持續時間

Pod 使用 kube-dns服務進行名稱解析。Kubernetes 使用目的地 NAT (DNAT) 將kube-dns流量從節點重新導向至 CoreDNS 後端 Pod。當您擴展 CoreDNS 部署時， kube-proxy會更新節點上的 iptable 規則和鏈結，將 DNS 流量重新導向至 CoreDNS Pod。當您擴展時傳播新端點，並在縮減 CoreDNS 時刪除規則，可能需要 1 到 10 秒，取決於叢集的大小。

當 CoreDNS Pod 終止但節點的 iptables 規則尚未更新時，此傳播延遲可能會導致 DNS 查詢失敗。在此案例中，節點可能會繼續將 DNS 查詢傳送至已終止的 CoreDNS Pod。

您可以在 CoreDNS Pod 中設定 lameduck 持續時間，以減少 DNS 查詢失敗。在層壓模式時，CoreDNS 將繼續回應傳輸中的請求。設定 lameduck 持續時間將延遲 CoreDNS 關機程序，允許節點更新其 iptables 規則和鏈結所需的時間。

我們建議將 CoreDNS lameduck 持續時間設定為 30 秒。

CoreDNS 準備程度探查

我們建議您使用 /ready，而非 /health用於 CoreDNS 的整備探查。

與先前的建議一致，將層壓持續時間設定為 30 秒，為節點的 iptables 規則提供足夠的時間，以便在 Pod 終止之前更新，採用 /ready 而不是 /health CoreDNS 整備探查，可確保 CoreDNS Pod 在啟動時完全準備好，以快速回應 DNS 請求。

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

如需 CoreDNS Ready 外掛程式的詳細資訊，請參閱 https：//https://coredns.io/plugins/ready/

記錄和監控代理程式

記錄和監控代理程式可以為您的叢集控制平面新增大量負載，因為代理程式會查詢 API 伺服器，以使用工作負載中繼資料豐富日誌和指標。節點上的代理程式只能存取本機節點資源，以查看容器和程序名稱等物件。查詢 API 伺服器可以新增更多詳細資訊，例如 Kubernetes 部署名稱和標籤。這對於故障診斷非常有用，但對擴展不利。

由於記錄和監控有許多不同的選項，我們無法顯示每個供應商的範例。使用 fluentbit 時，我們建議啟用 Use_Kubelet 以從本機 kubelet 而非 Kubernetes API Server 擷取中繼資料，並將 Kube_Meta_Cache_TTL設定為可在資料快取時減少重複呼叫的數字 （例如 60)。

擴展監控和記錄有兩個一般選項：

• 停用整合

• 取樣和篩選

停用整合通常不是選項，因為您遺失了日誌中繼資料。這樣可以消除 API 擴展問題，但它會在需要時沒有所需的中繼資料來引入其他問題。

抽樣和篩選可減少收集的指標和日誌數量。這將減少對 Kubernetes API 的請求量，並降低收集的指標和日誌所需的儲存量。降低儲存成本可降低整體系統的成本。

設定抽樣的能力取決於代理程式軟體，並且可以在不同的擷取點實作。請務必盡可能將抽樣新增至接近客服人員的位置，因為 API 伺服器呼叫可能發生的位置。請聯絡您的供應商，以進一步了解抽樣支援。

如果您使用的是 CloudWatch 和 CloudWatch Logs，則可以使用文件中描述的模式來新增代理程式篩選。

為了避免遺失日誌和指標，您應該將資料傳送到可在接收端點發生中斷時緩衝資料的系統。透過 fluentbit，您可以使用 Amazon Kinesis Data Firehose 暫時保留資料，以減少最終資料儲存位置超載的機會。