Kubernetes ネットワーク障害の詳細なトレースを記録する

ある夜、Kubernetes クラスターが拡張に失敗し続け、すべてのノードがクラスターに正常に参加できないという問題が発生しました。何度も試しても解決に至らなかったため、技術サポートのフィードバックをいただきました。この問題のトラブルシューティングプロセス全体は非常に興味深いので、使用したトラブルシューティングのアイデアと方法を整理して共有したいと思います。

[[401640]]

問題現象

運用チームが顧客の Kubernetes クラスターのノード容量を拡張していたとき、新しいノードの追加が常に失敗していることに気付きました。学生は次のように予備調査を実施した。

新しく追加されたノードでは、Kubernetes マスターサービスの VIP ネットワークにアクセスできません。
新しく追加されたノードで、Kubernetes マスターホスト IP + 6443 ネットワークに直接アクセスします。
新しく追加されたノードでは、他のノードのコンテナ IP アドレスを正常に ping できます。
新しく追加されたノードで、corednsサービスvipネットワークにアクセスすると正常になります

この顧客が使用している Kubernetes のバージョンは 1.13.10 で、ホストのカーネルバージョンは 4.18 (CentOS 8.2) です。

トラブルシューティングのプロセス

最前線の同僚からのフィードバックを受けて、当初は問題は IPVS にあるのではないかと疑いました。ネットワークの問題のトラブルシューティングに関する過去の経験に基づいて、まず現場でいくつかの定期検査を実施しました。

カーネルモジュール ip_tables がロードされているか確認する (正常)
iptable forward がデフォルト (通常) に設定されているかどうかを確認します。
ホストネットワークが正常かどうか確認する（正常）
コンテナネットワークが正常か確認する（正常）
…

共通の問題を排除した後、基本的に範囲を絞り込み、その後、IPVS 関連の側面に基づいて調査を継続できます。

ipvsadm コマンドによるトラブルシューティング

10.96.0.1 は、顧客クラスターの Kubernetes マスターサービス VIP です。

SYN_RECV 状態で接続異常が発生していることがわかり、起動時には kubelet + kube-proxy が正常に接続されていることが確認でき、起動後に Kubernetes サービスネットワークに異常が発生していることがわかります。

tcpdump パケットキャプチャ分析

両端でパケットをキャプチャし、telnet 10.96.0.1 443 コマンドを使用して確認します。

結論: このマシンでは SYN パケットが送信されていないことが判明しました。

予備的概要

上記のトラブルシューティングにより、範囲を再度絞り込むことができ、問題は基本的に kube-proxy にあることがわかります。私たちは IPVS モードを使用し、ネットワーク転送、SNAT、ドロップなどを実装するために iptables 構成にも依存しています。

上記のトラブルシューティングプロセスに基づいて範囲を絞り込み、疑わしいオブジェクト kube-proxy の分析を開始しました。

kube-proxy ログを表示する

異常なログが見つかり、iptables-restore コマンドが異常実行されました。問題を確認するには、Google とコミュニティをチェックしてください。

さらに深く

コード (1.13.10 バージョン pkg/proxy/ipvs/proxier.go:1427) を見ると、このバージョンには KUBE-MARK-DROP が存在するかどうかを判断して作成するロジックがないことがわかります。チェーンが存在しない場合は論理的な欠陥が発生し、iptable コマンドの実行が失敗します。

Kubernetes マスターサービスの VIP にアクセスできないのに、実際のコンテナー関連の IP にアクセスできる理由は、次の iptable ルールに関連しています。

 iptables -t nat -A KUBE-SERVICES ! -s 9.0.0.0/8 -m comment --comment "Kubernetes サービス クラスター IP + マスカレード目的のポート" -m set --match-set KUBE-CLUSTER-IP dst,dst -j KUBE-MARK-MASQ

根本原因の調査

すでにご存知のとおり、kube-proxy 1.13.10 には欠陥があります。 KUBE-MARK-DROP チェーンが作成されていない場合は、iptables-restore コマンドを実行してルールを設定します。しかし、Kubernetes バージョン 1.13.10 は、CentOS 8.2 4.18 カーネルオペレーティングシステムで実行するとエラーが報告されるのに、CentOS 7.6 3.10 カーネルオペレーティングシステムでは正常に実行されるのはなぜでしょうか?

kube-proxy のソースコードを見ると、kube-proxy が実際に iptables コマンドを実行してルールを設定していることがわかります。 kube-proxy は iptables-restore コマンドが失敗したというエラーを報告しているので、4.18 カーネルを搭載したマシンを見つけて kube-proxy コンテナに入り、状況を確認します。

コンテナ内で iptables-save コマンドを実行すると、KUBE-MARK-DROP チェーンが kube-proxy コンテナ内に作成されていないことがわかります (コードで予想されるとおり)。ホストマシン上で iptables-save コマンドを実行し続けたところ、KUBE-MARK-DROP チェーンがあることがわかりました。

ここでは2つの質問があります:

4.18 カーネルホストの iptables に KUBE-MARK-DROP チェーンがあるのはなぜですか?
4.18 カーネルホストの iptables ルールが kube-proxy コンテナのルールと一致しないのはなぜですか?

最初の疑問は、kube-proxy 以外にも iptables を操作するプログラムがあるのではないかと疑っているため、Kubernetes のコードを読み進めています。

結論: kube-proxy に加えて、kubelet も iptables ルールを変更することがわかりました。具体的なコードについては、pkg/kubelet/kubelet_network_linux.go を参照してください。

2 番目の疑問については、自分の感覚に従ってください。 Google は、kube-proxy コンテナが host/run/xtables.lock ファイルをマウントしたときに、ホストとコンテナの iptables が異なるルールを表示する理由を尋ねました。

結論: CentOS 8 はネットワークに関して iptables を放棄し、デフォルトのネットワークパケットフィルタリングツールとして nftables フレームワークを採用しています。

この時点で、すべての謎は解明されました。

チームは多数の顧客プロジェクトの納品を完了しましたが、まだ答えられる質問がいくつかあります。

質問 1: なぜこれほど多くの顧客環境で初めてこの問題が発生するのでしょうか? Kubernetes 1.13.10 + Centos 8.2 オペレーティングシステムが必要なので、この組み合わせはまれであり、問題は必ず発生します。 Kubernetes 1.16.0 以降にアップグレードすると、この問題は発生しません。
質問 2: Kubernetes 1.13.10 + 5.5 カーネルを使用すると、なぜこのような問題が発生しないのでしょうか?

これは CentOS 8 オペレーティングシステムに関連しているため、手動でバージョン 5.5 にアップグレードした後も、iptables フレームワークはデフォルトで引き続き使用されます。

nftables が使用されているかどうかを確認するには、iptables -v コマンドを使用できます。

nftablesとは何ですか? iptables よりも優れていますか?これはさらに研究する価値のあるもう一つの点なので、ここでは詳しくは触れません。