翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ネットワーク切断によるアプリケーションネットワークトラフィック
このページのトピックは、Kubernetes クラスターネットワークと、ノードと Kubernetes コントロールプレーン間のネットワーク切断中のアプリケーショントラフィックに関連しています。
## Cilium
Cilium には、IP アドレス管理 (IPAM)、カプセル化、ロードバランシング、クラスタールーティングのためのいくつかのモードがあります。このガイドで検証されたモードは、クラスタースコープ IPAM、VXLAN オーバーレイ、BGP 負荷分散、kube-proxy を使用していました。Cilium も BGP 負荷分散なしで使用され、MetalLB L2 負荷分散に置き換えられました。
Cilium インストールのベースは、Cilium オペレーターと Cilium エージェントで構成されます。Cilium 演算子はデプロイとして実行され、Cilium Custom Resource Definitions (CRDs を登録し、IPAM を管理し、クラスターオブジェクトを [https://docs.cilium.io/en/stable/internals/cilium_operator/](https://docs.cilium.io/en/stable/internals/cilium_operator/)Kubernetes API サーバーと同期します。Cilium エージェントは、各ノードで DaemonSet として実行され、クラスターで実行されているワークロードのネットワークルールを制御する eBPF プログラムを管理します。
一般的に、Cilium によって設定されたクラスター内ルーティングは、ネットワーク切断中も引き続き利用可能であり、インプレースです。これは、ポッドネットワークのクラスター内トラフィックフローと IP テーブル (iptables) ルールを監視することで確認できます。
```
ip route show table all | grep cilium
```
```
10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16
10.86.3.16 dev cilium_host proto kernel scope link
...
```
ただし、ネットワークの切断中、Cilium オペレーターと Cilium エージェントは、ヘルスチェックと Kubernetes API サーバーへの接続のヘルスが結合されているため、再起動します。ネットワークの切断中に Cilium オペレーターと Cilium エージェントのログに以下が表示されることが予想されます。ネットワークの切断中に、 CLI `crictl` などのツールを使用して、ログを含むこれらのコンポーネントの再起動を監視できます。
```
msg="Started gops server" address="127.0.0.1:9890" subsys=gops
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client
msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s
msg=Stopping
msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops
msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon
```
アプリケーションの負荷分散に Cilium の BGP コントロールプレーン機能を使用している場合、BGP スピーカー機能が Cilium エージェントと統合されており、Kubernetes コントロールプレーンから切断されると Cilium エージェントが継続的に再起動するため、ポッドとサービスの BGP セッションがネットワークの切断中にダウンする可能性があります。詳細については、Cilium ドキュメントの「Cilium BGP コントロールプレーンオペレーションガイド」を参照してください。さらに、電源サイクルやマシンの再起動など、ネットワークの切断中に同時に障害が発生した場合、Cilium ルートはこれらのアクションによって保持されませんが、ノードが Kubernetes コントロールプレーンに再接続して Cilium が再び起動すると、ルートは再作成されます。
## Calico
*近日リリース*
## MetalLB
MetalLB には、L2 モードと [BGP](https://metallb.universe.tf/concepts/bgp/) モードの [L2 ](https://metallb.universe.tf/concepts/layer2/)つのロードバランシングモードがあります。これらの負荷分散モードの仕組みとその制限の詳細については、MetalLB ドキュメントを参照してください。このガイドの検証では、L2 モードで MetalLB を使用し、クラスター内の 1 台のマシンが Kubernetes サービスの所有権を取得し、IPv4 の ARP を使用してロードバランサーの IP アドレスをローカルネットワークで到達可能にします。MetalLB を実行する場合、IP 割り当てを担当するコントローラーと、割り当てられた IP アドレスを持つ サービスをアドバタイズする各ノードで実行されるスピーカーがあります。MetalLB コントローラーはデプロイとして実行され、MetalLB スピーカーは DaemonSet として実行されます。ネットワークの切断中、MetalLB コントローラーとスピーカーはクラスターリソースの Kubernetes API サーバーを監視できませんが、実行は続行されます。最も重要なのは、外部接続に MetalLB を使用しているサービスは、ネットワークの切断中も引き続き利用可能でアクセス可能です。
## kube-proxy
EKS クラスターでは、kube-proxy は各ノードで DaemonSet として実行され、ネットワークルールを管理して、サービス IP アドレスを基盤となるポッドの IP アドレスに変換することで、サービスとポッド間の通信を有効にします。kube-proxy によって設定された IP テーブル (iptables) ルールは、ネットワークの切断中に維持され、クラスター内ルーティングは引き続き機能し、kube-proxy ポッドは引き続き実行されます。
kube-proxy ルールは、次の iptables コマンドで確認できます。最初のコマンドは、`PREROUTING`チェーンを通過するパケットが`KUBE-SERVICES`チェーンに誘導されることを示しています。
```
iptables -t nat -L PREROUTING
```
```
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
```
`KUBE-SERVICES` チェーンを調べると、さまざまなクラスターサービスのルールを確認できます。
```
Chain KUBE-SERVICES (2 references)
target prot opt source destination
KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP /
KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP /
KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP /
KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP /
KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP /
KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP /
KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP /
KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP /
KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP /
KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP /
KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP /
KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */
```
フロントエンドサービスのチェーンでアプリケーションを調べると、サービスを支えるポッド IP アドレスを確認できます。
```
iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q
```
```
Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references)
target prot opt source destination
KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349
KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000
KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */
```
次の kube-proxy ログメッセージは、Kubernetes API サーバーがノードおよびエンドポイントリソースの更新を監視しようとしたときに、ネットワークの切断中に予期されます。
```
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError"
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError"
```
## CoreDNS
デフォルトでは、EKS クラスターのポッドは、クラスター内 DNS クエリのネームサーバーとして CoreDNS クラスター IP アドレスを使用します。EKS クラスターでは、CoreDNS はノードのデプロイとして実行されます。ハイブリッドノードでは、ハイブリッドノードでローカルに実行されている CoreDNS レプリカがある場合、ポッドはネットワークの切断中に CoreDNS と通信し続けることができます。クラウドにノードを持つ EKS クラスターがあり、オンプレミス環境にハイブリッドノードがある場合は、各環境に少なくとも 1 つの CoreDNS レプリカを持つことをお勧めします。CoreDNS は、ネットワークの切断前に作成されたレコードの DNS クエリの処理を継続し、静的安定性のためにネットワーク再接続を通じて実行を継続します。
Kubernetes API サーバーからオブジェクトを一覧表示しようとすると、ネットワークの切断中に次の CoreDNS ログメッセージが予期されます。
```
Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout
Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout
Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout
```