Kubernetes の混乱から熟練へ: クラスター サービスの 3 つの重要なポイントと 1 つの実装

私の経験では、Kubernetes クラスター サービスの概念を理解するのは簡単ではありません。特に、サービス関連の問題を、根拠のない理解に基づいて解決しようとすると、非常に困難になります。

これは、初心者にとっては、サービスの IP アドレスに ping できないなどの基本的な問題でさえ理解するのが難しいという事実に反映されています。経験豊富なエンジニアであっても、サービスに関連する iptables 構成を理解するのは非常に困難です。

本日の記事では、Kubernetes クラスター サービスの原理と実装について、誰もが理解しやすいように詳しく説明します。

Kubernetes クラスター サービスの本質は何ですか?

概念的に言えば、Kubernetes クラスターのサービスは、実際には負荷分散またはリバース プロキシです。これは、Alibaba Cloud の負荷分散製品と多くの類似点があります。負荷分散と同様に、サービスには IP アドレスとフロントエンド ポートがあります。複数のコンテナ グループ ポッドがサービスの背後に「バックエンド サーバー」としてマウントされ、これらの「バックエンド サーバー」には独自の IP アドレスとリスニング ポートがあります。

このような負荷分散とバックエンド アーキテクチャを Kubernetes クラスターと組み合わせる場合、考えられる最も直感的な実装方法は、クラスター内のノードに負荷分散の役割を特に実行させ (LVS と同様)、他のノードを使用してバックエンド コンテナー グループの読み込みを行うことです。

この実装方法には、単一点の問題という大きな欠陥があります。 Kubernetes クラスタは、Google の長年にわたる自動化された運用とメンテナンスの実践の成果です。このような実装は、インテリジェントな運用と保守の理念に明らかに反しています。

独自のコミュニケーター

サイドカー パターンは、マイクロサービス分野の中核となる概念です。サイドカー モードとは、言い換えれば、通信機が内蔵されていることを意味します。サービスグリッドに精通している学生は、これについても理解している必要があります。しかし、Kubernetes クラスターの元のサービスの実装も Sidecar モデルに基づいていることに気付いている人はほとんどいないでしょう。

Kubernetes クラスターでは、サービスの実装は実際には各クラスター ノードにリバース プロキシ サイドカーをデプロイすることです。クラスター サービスへのすべてのアクセスは、ノード上のリバース プロキシによってサービス バックエンド コンテナー グループへのアクセスに変換されます。基本的に、ノードとこれらのサイドカーの関係は次の図に示されています。

サービスを現実のものに

前の 2 つのセクションでは、Kubernetes クラスターのサービスは本質的に負荷分散、つまりリバース プロキシであることを説明しました。同時に、実際の実装では、このリバース プロキシはクラスター内の特定のノードに展開されるのではなく、クラスター ノードのサイドカーとして各ノードに展開されることもわかっています。

ここでは、Kubernetes クラスターのコントローラーである kube-proxy を使用して、サービスをリバース プロキシに反映します。 Kubernetes クラスター コントローラーの原理については、コントローラーに関する私の別の記事を参照してください。簡単に言うと、kube-proxy はクラスター ノードにデプロイされたコントローラーであり、クラスター API サーバーを通じてクラスターのステータスの変化を監視します。新しいサービスが作成されると、kube-proxy はクラスター サービスのステータスとプロパティをリバース プロキシ構成に変換します。

残る問題は、上図の Proxy の実装であるリバース プロキシです。

1つの実装

現在、Kubernetes クラスター ノードがサービス リバース プロキシを実装するための主な方法は、ユーザー空間、iptables、IPVS の 3 つです。今日は、iptables メソッドのみを詳細に分析します。基盤となるネットワークは、Alibaba Cloud Flannel クラスター ネットワークに基づいています。

フィルターフレームワーク

さて、シナリオを想像してみましょう。私たちには家があります。この家には入口パイプと出口パイプがあります。給水管から入ってくる水には不純物が含まれているため、そのまま飲むことはできません。水道管から流れ出る水はそのまま飲めるものと期待しています。これを実現するために、水道管を切断し、途中にゴミフィルターを追加しました。

数日後、私たちのニーズは変化しました。私たちは、家から流れ出る水がそのまま飲めるだけでなく、お湯としても使えるようにしたいと考えていました。そのため、水道管にさらに切り込みを入れ、ヒーターを追加する必要がありました。

明らかに、パイプを切断して新しい機能を追加するこの方法は醜いです。需要はいつでも変化する可能性があるため、1～2年後に水道管を切断する場所がまだあることを保証するのは困難です。

したがって、再設計する必要があります。まず第一に、私たちは

水道管が切れているので、水道管の切れ目を修理する必要があります。上記のシナリオを例にとると、水道管の切断位置は 1 か所だけであることがわかります。次に、水を処理する 2 つの方法、つまり物理的変化と化学的変化を抽象化します。

上記の設計に基づいて、不純物をフィルタリングする必要がある場合は、化学変化機能モジュールに不純物をフィルタリングするためのルールを追加できます。温度を上げる必要がある場合は、物理的変化関数モジュールに加熱ルールを追加できます。

上記のフィルターフレームワークは、水道管を切断する方法よりも明らかに優れています。このフレームワークを設計するにあたり、私たちは主に 2 つのことを行いました。1 つは水道管の切り欠きの位置を固定すること、もう 1 つは 2 つの水処理方法を抽象化することです。

これら 2 つのことを理解した後、iptables、より正確には netfilter がどのように機能するかを見てみましょう。 Netfilter は実際にはフィルター フレームワークです。 Netfilter は、ネットワーク パケットの送信、受信、ルーティングを行うパイプライン上の合計 5 つのポート (PREROUTING、FORWARD、POSTROUTING、INPUT、OUTPUT) をカットします。同時に、netfilter は NAT やフィルターを含むいくつかのネットワーク パケット処理方法を定義します。

ルーティングと転送により、上記のネットフィルターの複雑さが大幅に増加することに注意してください。ルーティングと転送を考慮しなければ、netfilter は水質フィルター フレームワークと同じくらい単純なものになります。

ノードネットワーク図

それでは、Kubernetes クラスター ノードの全体的なネットワークを見てみましょう。水平的な観点から見ると、ノード上のネットワーク環境は、ホスト ネットワーク名前空間や Pod ネットワーク名前空間など、さまざまなネットワーク名前空間に分割されます。垂直的な観点から見ると、各ネットワーク名前空間には、アプリケーションからプロトコル スタック、そしてネットワーク デバイスまでの完全なネットワーク スタックが含まれます。

ネットワーク デバイス層では、cni0 仮想ブリッジを使用してシステム内に仮想 LAN を構築します。 Pod ネットワークは、veth ペアを介してこの仮想 LAN に接続されます。 cni0 仮想 LAN は、ホスト ルータとネットワーク ポート eth0 を介して外部と通信します。

ネットワーク プロトコル スタック層では、netfilter フィルター フレームワークをプログラミングすることで、クラスター ノードのリバース プロキシを実装できます。

リバース プロキシを実装するには、最終的には DNAT を実行する必要があります。つまり、クラスター サービスの IP とポートに送信されたデータ パケットを、特定のコンテナー グループに送信される IP とポートに変更する必要があります。

netfilter フィルタ フレームワークの図を参照すると、netfilter では、PREROUTING、OUTPUT、POSTROUGING の 3 つの位置に NAT ルールを追加することで、データ パケットの送信元アドレスまたは宛先アドレスを変更できることがわかります。

ここで行う必要があるのは DNAT、つまり宛先アドレスの変更であるため、データ パケットがルーティングによって正しく処理されることを保証するために、このような変更はルーティング (ROUTING) の前に行われる必要があり、リバース プロキシを実装するためのルールを PREROUTING と OUTPUT の両方に追加する必要があります。

その中で、PREOURTING ルールは、Pod からサービスへのトラフィックを処理するために使用されます。データ パケットは Pod ネットワーク veth から cni0 に送信された後、ホスト プロトコル スタックに入り、最初に netfilter PREROUTING によって処理されます。したがって、サービスに送信されたデータ パケットはこの場所で DNAT されます。 DNAT 処理後、データ パケットの宛先アドレスは別の Pod のアドレスになり、ホスト ルーティングを介して eth0 に転送され、正しいクラスター ノードに送信されます。

OUTPUT 位置に追加された DNAT ルールは、ホスト ネットワークからサービスに送信されるデータ パケットを処理するために使用されます。原理は同様で、ルーティング転送を容易にするために、ルーティング前に宛先アドレスが変更されます。

フィルタフレームワークのアップグレード

フィルター フレームワークのセクションでは、netfilter がフィルター フレームワークであることを説明しました。 Netfilter はデータ「パイプライン」上の 5 つのポートを切断し、これらの 5 つのポートでデータ パケット処理作業を実行します。固定された切開位置とネットワーク パケット処理方法の分類により、フィルター フレームワークは大幅に最適化されましたが、新しい機能に対応するためにパイプラインを変更する必要があるという重要な問題がまだ残っています。つまり、このフレームワークはパイプラインとフィルタリング機能を完全に分離しません。

パイプラインとフィルタリング機能を分離するために、netfilter はテーブルの概念を使用します。テーブルはNetfilterのフィルタリングセンターです。その中心的な機能は、フィルタリング方法（テーブル）を分類し、各フィルタリング方法におけるフィルタリングルール（チェーン）を整理することです。

フィルタリング機能をパイプラインから分離すると、すべてのデータ パケット処理はテーブル構成になります。パイプの 5 つの切り込みは、トラフィックの入口と出口となり、トラフィックを濾過センターに送信し、処理されたトラフィックをパイプに沿って送信し続ける役割を果たします。

上の図に示すように、表では、netfilter はルールをチェーンに編成します。テーブルには、各パイプ カットアウトのデフォルトのチェーンと、独自に追加したカスタム チェーンが含まれています。デフォルト チェーンはデータのエントリ ポイントです。デフォルト チェーンは、カスタム チェーンにジャンプすることで、いくつかの複雑な機能を完了できます。ここでカスタム チェーンを追加できるようにする利点は明らかです。 Kubernetes クラスター ノードのリバース プロキシの実装など、複雑なフィルタリング機能を完成させるために、カスタム チェーンを使用してルールをモジュール化できます。

カスタムチェーンを使用したサービス用のリバースプロキシの実装

クラスター サービスのリバース プロキシは、実際にはカスタム チェーンを使用して、データ パケットの DNAT 変換をモジュール方式で実装します。 KUBE-SERVICE はリバース プロキシ全体のエントリ チェーンであり、すべてのサービスの合計エントリに対応します。 KUBE-SVC-XXXX チェーンは、特定のサービスのエントリ チェーンです。 KUBE-SERVICE チェーンは、サービス IP に応じて特定のサービスの KUBE-SVC-XXXX チェーンにジャンプします。 KUBE-SEP-XXXX チェーンは、特定の Pod、つまりエンドポイントのアドレスとポートを表します。特定のサービス チェーン KUBE-SVC-XXXX は、特定のアルゴリズム (通常はランダム) に従ってエンドポイント チェーンにジャンプします。

前述のように、ここで行う必要があるのは DNAT、つまり宛先アドレスの変更であるため、データ パケットがルーターによって正しく処理されることを保証するために、ルーティングの前にこのような変更を行う必要があります。したがって、KUBE-SERVICE は 2 つのデフォルト チェーン PREROUTING と OUTPUT によって呼び出されます。

要約する

この記事を通じて、Kubernetes クラスター サービスの概念と実装について、誰もがより深く理解できるようになります。基本的には3つの重要なポイントを把握する必要があります。 1. このサービスは本質的に負荷分散サービスです。 2. サービス負荷分散の実装では、LVS タイプの専用モデルではなく、サービス メッシュに類似したサイドカー モデルを使用します。 3. Kube-proxy は本質的にはクラスター コントローラーです。さらに、フィルター フレームワークの設計について検討し、これに基づいて、iptables を使用して実装されるサービス負荷分散の原則を理解しました。