本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 透過網路連線的穩定性最佳實務
<a name="hybrid-nodes-network-disconnection-best-practices"></a>

## 高可用性的聯網
<a name="_highly_available_networking"></a>

避免混合節點與 Kubernetes 控制平面之間中斷網路連線的最佳方法是使用備援、彈性的內部部署環境與 AWS 之間的連線。如需使用這些解決方案建構高可用性混合網路的詳細資訊，請參閱 [AWS Direct Connect 彈性工具組](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html)和 [AWS Site-to-Site VPN 文件](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html)。

## 高度可用的應用程式
<a name="_highly_available_applications"></a>

架構應用程式時，請考慮您的故障網域和不同類型的中斷的影響。Kubernetes 提供內建機制，可跨節點、區域和區域網域部署和維護應用程式複本。這些機制的使用取決於您的應用程式架構、環境和可用性需求。例如，無狀態應用程式通常可以使用多個複本部署，並且可以在任意主機和基礎設施容量之間移動，而且您可以使用節點選擇器和拓撲分散限制條件，在不同網域之間執行應用程式的執行個體。如需在 Kubernetes 上建置彈性應用程式的應用程式層級技術詳細資訊，請參閱 [EKS 最佳實務指南](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/)。

Kubernetes 會在決定是否將 Pod 移至其他節點時，評估與 Kubernetes 控制平面中斷連接的節點的區域資訊。如果區域中的所有節點都無法連線，Kubernetes 會取消該區域中節點的 Pod 移出。最佳實務是，如果您部署的節點在多個資料中心或實體位置執行，請根據其資料中心或實體位置將區域指派給每個節點。當您使用雲端中的節點執行 EKS 時，AWS cloud-controller-manager 會自動套用此區域標籤。不過，cloud-controller-manager 不會與混合節點搭配使用，因此您可以透過 kubelet 組態傳遞此資訊。如何在混合節點的節點組態中設定區域的範例如下所示。當您使用混合節點 CLI () 將混合節點連接至叢集時，會傳遞組態`nodeadm`。如需`topology.kubernetes.io/zone`標籤的詳細資訊，請參閱 [Kubernetes 文件](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone)。如需混合節點 CLI 的詳細資訊，請參閱[混合節點節點廣告參考](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html)。

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    region: my-region
  kubelet:
    flags:
       - --node-labels=topology.kubernetes.io/zone=dc1
  hybrid:
    ...
```

## 網路監控
<a name="_network_monitoring"></a>

如果您使用 AWS Direct Connect 或 AWS Site-to-Site VPN 進行混合連線，則可以利用 CloudWatch 警示、日誌和指標來觀察混合連線的狀態並診斷問題。如需詳細資訊，請參閱[監控 AWS Direct Connect 資源](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html)和[監控 AWS Site-to-Site VPN 連接](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html)。

建議為在 EKS 控制平面上執行的node-lifecycle-controller所報告`NodeNotReady`的事件建立警示，這表示混合節點可能正在發生網路連線中斷。您可以為 Controller Manager 啟用 EKS 控制平面記錄，並在 CloudWatch 中為狀態為「NodeNotReady」的「節點記錄狀態變更事件訊息」訊息建立指標篩選條件，以建立此警示。建立指標篩選條件後，您可以根據所需的閾值為此篩選條件建立警示。如需詳細資訊，請參閱 [ CloudWatch 文件中的日誌警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)。

您可以使用 Transit Gateway (TGW) 和 Virtual Private Gateway (VGW) 內建指標來觀察進出 TGW 或 VGW 的網路流量。您可以為這些指標建立警示，以偵測網路流量低於正常層級的情況，指出混合節點和 EKS 控制平面之間可能發生網路問題。下表說明 TGW 和 VGW 指標。


| 閘道 | 指標 | Description | 
| --- | --- | --- | 
|  轉換閘道  |  BytesIn  |  TGW 從附件接收的位元組 (EKS 控制平面到混合節點）  | 
|  轉換閘道  |  BytesOut  |  從 TGW 傳送至附件的位元組 （混合節點至 EKS 控制平面）  | 
|  虛擬私有閘道  |  TunnelDataIn  |  從連線的 AWS 端透過 VPN 通道傳送到客戶閘道的位元組 (EKS 控制平面到混合節點）  | 
|  虛擬私有閘道  |  TunnelDataOut  |  從客戶閘道透過 VPN 通道在連線的 AWS 端接收的位元組 （混合節點到 EKS 控制平面）  | 

您也可以使用 [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/) 深入了解混合連線，以減少復原的平均時間，並判斷網路問題是源自 AWS 還是您的環境。CloudWatch Network Monitor 可用來視覺化混合網路連線中的封包遺失和延遲、設定警示和閾值，然後採取行動來改善網路效能。如需詳細資訊，請參閱[使用 Amazon CloudWatch Network Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)。

EKS 提供多種選項來監控叢集和應用程式的運作狀態。對於叢集運作狀態，您可以使用 EKS 主控台中的可觀測性儀表板來快速偵測、疑難排解和修復問題。您也可以使用 Amazon Managed Service for Prometheus、AWS Distro for Open Telemetry (ADOT) 和 CloudWatch 進行叢集、應用程式和基礎設施監控。如需 EKS 可觀測性選項的詳細資訊，請參閱[監控叢集效能和檢視日誌](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html)。

## 本機故障診斷
<a name="_local_troubleshooting"></a>

若要準備混合節點和 EKS 控制平面之間的網路連線中斷，您可以設定次要監控和記錄後端，以在區域 AWS 服務無法連線時維持應用程式的可觀測性。例如，您可以設定 AWS Distro for Open Telemetry (ADOT) 收集器，將指標和日誌傳送至多個後端。您也可以使用本機工具，例如 `crictl` CLI，在本機與 Pod 和容器互動，以取代 `kubectl`或其他通常查詢 Kubernetes API 伺服器端點的 Kubernetes API 相容用戶端。如需 的詳細資訊`crictl`，請參閱 cri-tools GitHub 中的 [`crictl` 文件](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。以下列出一些有用的`crictl`命令。

列出在主機上執行的 Pod：

```
crictl pods
```

列出在主機上執行的容器：

```
crictl ps
```

列出在主機上執行的映像：

```
crictl images
```

取得在主機上執行之容器的日誌：

```
crictl logs CONTAINER_NAME
```

取得在主機上執行的 Pod 統計資料：

```
crictl statsp
```

## 應用程式網路流量
<a name="_application_network_traffic"></a>

使用混合節點時，請務必考慮並了解應用程式流量的網路流程，以及您用來向叢集外部公開應用程式的技術。不同的應用程式負載平衡和傳入技術在網路連線中斷期間會有不同的行為。例如，如果您使用 Cilium 的 BGP 控制平面功能進行應用程式負載平衡，則 Pod 和服務的 BGP 工作階段可能會在網路連線中斷期間關閉。這是因為 BGP 發言者功能與 Cilium 代理程式整合，並且 Cilium 代理程式會在與 Kubernetes 控制平面中斷連線時持續重新啟動。重新啟動的原因是因為 Cilium 的運作狀態檢查失敗，因為其運作狀態與 Kubernetes 控制平面的存取權結合 （請參閱 [CFP：\$131702](https://github.com/cilium/cilium/issues/31702) 搭配 Cilium v1.17 的選擇加入改進）。同樣地，如果您將 Application Load Balancer (ALB) 或 Network Load Balancer (NLB) 用於 AWS 區域來源的應用程式流量，則如果您的現場部署環境失去與 AWS 區域的連線，則該流量可能會暫時中斷。建議在部署到生產環境之前，先驗證您用於負載平衡和傳入的技術在網路連線中斷期間是否保持穩定。[aws-samples/eks-hybrid-examples](https://github.com/aws-samples/eks-hybrid-examples) GitHub 儲存庫中的範例使用 MetalLB 在 [L2 模式下](https://metallb.universe.tf/concepts/layer2/)進行負載平衡，這在混合節點和 EKS 控制平面之間的網路連線中斷期間保持穩定。

## 檢閱遠端 AWS 服務的相依性
<a name="_review_dependencies_on_remote_aws_services"></a>

使用混合節點時，請注意您在內部部署或邊緣環境外部的區域 AWS 服務上採取的相依性。範例包括存取 Amazon S3 或 Amazon RDS 以取得應用程式資料、使用 Amazon Managed Service for Prometheus 或 CloudWatch 取得指標和日誌、使用 Application and Network Load Balancer 取得區域來源流量，以及從 Amazon Elastic Container Registry 提取容器。在內部部署環境和 AWS 之間的網路連線中斷期間，將無法存取這些服務。如果您的內部部署環境容易與 AWS 中斷網路連線，請檢閱 AWS 服務的使用情況，並確保失去與這些服務的連線不會影響應用程式的靜態穩定性。

## 調校 Kubernetes Pod 容錯移轉行為
<a name="_tune_kubernetes_pod_failover_behavior"></a>

對於非跨主機可攜式的應用程式，或資源受限的環境，如果沒有 Pod 容錯移轉的備用容量，可以選擇在網路連線中斷期間調整 Pod 容錯移轉行為。一般而言，請務必考慮您應用程式的資源需求，並有足夠的容量讓一或多個應用程式執行個體在節點故障時容錯移轉至不同的主機。
+  選項 1 - 使用 DaemonSets：此選項適用於可以且應該在叢集中所有節點上執行的應用程式。DaemonSets 會自動設定為容忍無法連線的污點，這會讓 DaemonSet Pod 透過網路連線來繫結至其節點。
+  選項 2 - 針對無法連線`tolerationSeconds`的污點進行調校：您可以調校裝置在網路連線中斷期間與節點繫結的時間。透過設定應用程式 Pod 來容忍無法連線的污點，在您指定的持續時間 (`tolerationSeconds`在應用程式規格中） 內產生`NoExecute`效果。使用此選項時，當發生網路連線中斷時，您的應用程式 Pod 會持續繫結至節點，直到 `tolerationSeconds` 到期為止。仔細考慮這一點，因為使用 `tolerationSeconds`增加無法連線污點`NoExecute`意味著在無法連線的主機上執行的 Pod 可能需要更長的時間才能移至其他可連線且運作狀態良好的主機。
+  選項 3：自訂控制器：您可以建立並執行自訂控制器 （或其他軟體），以監控 Kubernetes 是否有無法連線的污點並產生`NoExecute`效果。偵測到此污點時，自訂控制器可以檢查應用程式特定的指標，以評估應用程式運作狀態。如果應用程式狀態良好，自訂控制器可以移除無法連線的污點，防止在網路連線中斷期間從節點移出 Pod。

以下顯示如何使用 `tolerationSeconds`為無法連線的污點設定部署的範例。在此範例中， `tolerationSeconds` 設定為 `1800`(30 分鐘），這表示只有在網路連線中斷持續超過 30 分鐘時，才會移出在無法連線的節點上執行的 Pod。

```
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 1800
```