目次
序文
前回の記事【k8s】VII. Podの詳しい解説(1)では、 Podの基本的な考え方や分類、Podのコントローラーの種類について簡単に紹介しましたが、本記事ではさらにPodのネットワークについて紹介します。コンセプトが絡むものが多いので、根気よく見ていく必要があります。しかし、k8s のネットワークは Pod ネットワークだけでなく、サービス ネットワークでもあります。
k8s の実験環境がない場合は、以前の記事を参照してください。
Pod ネットワーク通信方式
K8S のネットワーク モデルは、すべての Pod が直接接続できるフラットなネットワーク空間にあること、つまり、すべての Pod が相手の IP を介して直接到達できることを前提としています。これは GCE (Google Compute Engine) の既製のネットワーク モデルであり、K8S はこのネットワークが既に存在することを前提としています。プライベート クラウドで K8S クラスターを構築する場合、ネットワークが既に存在することを前提とすることはできません.このネットワークの前提を自分で実装し、最初に異なるノード上のコンテナー間の相互アクセスを開き、K8S を実行する必要があります。
さまざまな状況でのネットワーク通信方法
同じ Pod 内の通信
同じポッド内の複数のコンテナーは、lo を介して通信します。同じ Pod は、同じネットワーク名前空間と同じ Linux プロトコル スタックを共有します。k8s がコンテナを起動すると、まず一時停止コンテナが起動され、このコンテナがこの機能を実現します。上の図のように、コンテナ間には localhost ネットワークがあるため、同じ Pod 内のコンテナ サービスのポートを繰り返すことはできません。そうしないと、エラーが報告されます。
Pod 間の通信
ポッドは同じマシン上にあります
コンテナーが Docker を使用している場合は、docker0 ブリッジを介して直接転送します。
コンテナーが Containerd を使用する場合、CNI を介して直接転送されます。
図に示すように、Pod1 の IP は 172.12.0.100、Pod2 の IP は 172.12.0.101、2 つの Pod は 172.12.0.1 のネットワーク セグメントの下にあります。
ポッドは異なるマシン上にあります
Pod アドレスは同じネットワーク セグメントにありますが、CNI/docker0 ネットワーク セグメントとホスト ネットワーク カードは 2 つの完全に異なる IP ネットワーク セグメントであり、異なるノード間の通信はホスト マシンの物理ネットワーク カードを介してのみ実行できます。 . Pod の IP をそれが配置されている Node の IP に関連付けます。この関連付けにより、Pod は相互にアクセスできます。この時点で、Pod 間の通信は Overlay Network 経由でアクセスできます。
オーバーレイ ネットワーク (Overlay Network) は、既存のネットワーク上に仮想的なネットワークを構築することで、flannel/weavenet/calico など多くの実装技術がありますが、これらのソリューションのほとんどはトンネル パケット技術を使用しています。Pod ネットワークのデータ パケットは、ノードを離れる前にノード ネットワークのデータ パケットにカプセル化されます. データ パケットがターゲット ノードに到達すると、パケット内の Pod ネットワーク データ パケットはカプセル化解除され、内部に転送されます.ノードの Pod ネットワーク。このソリューションは、基盤となるネットワークに特別に依存することはありませんが、パケットのアンパッキングにより、パフォーマンスのオーバーヘッドが追加されます。
Pod と Service 間の通信
各ノードは維持され、iptables を介して転送されます。ポッドからサービスへのネットワークは、k8s の新しいバージョンの LVS に基づいて維持および転送されます
Pod は外部ネットワークと通信します
外部ネットワークへのポッド
Pod は外部ネットワークにリクエストを送信し、ルーティング テーブルを検索し、データ パケットをホスト マシンのネットワーク カードに転送します. ホスト マシンのネットワーク カードがルーティングの選択を完了すると、iptables はマスカレードを実行し、送信元を変更します. IP をホスト ネットワーク カードの IP に変換してから、外部ネットワーク サーバーに要求を送信します。
Pod への外部ネットワーク
サービスを介してアクセスします。
CNI
先ほど、異なるマシン上の Pod の通信方法がオーバーレイ ネットワークを介して確立されることを説明しました。上記の概略図でも CNI について言及しました。では、CNIとは何ですか？
CNIとは
CNI、その正式名称は Container Network Interface で、コンテナ ネットワークの API インターフェイスです。
Google と coreos が共同開発したネットワーク標準であり、k8s ネットワーク プラグインを実装するための基盤となる、ネットワーク実装を呼び出すための K8s の標準インターフェイスです。Kubelet uses this standard API to call different network plug-ins to implement different network configuration methods. このインターフェイスを実装するのは、一連の CNI API インターフェイスを実装する CNI プラグインです。一般的な CNI プラグインには、Calico、flannel、Terway、Weave Net、Contiv などがあります。
今回の実験環境で使用した CNI プラグインは Flannel です。特定のネットワーク初期化手順は、[k8s] 3. k8s クラスターの初期化にあります。フランネルについて簡単に紹介しましょう
フランネル
Flannel は、CoreOs チームが Kubernetes 用に設計したネットワーク プランニング サービスです. 簡単に言えば、その機能は、クラスター内の異なるノード ホストによって作成されたコンテナーが、クラスター全体に対して一意の仮想 IP アドレスを持つことを可能にすることです. また、これらの IP アドレス間にオーバーレイ ネットワーク (overlay Network) を確立することもでき、このオーバーレイ ネットワークを介して、データ パケットはそのままターゲット コンテナーに配信されます。
Flannel のネットワーク リクエスト パス
Flannel は本質的に「オーバーレイ ネットワーク」、つまりルーティング、転送、通信のために TCP データを別のネットワーク パケットにパッケージ化するもので、現在、UDP、VxLAN、AWS VPC、GCE ルーティングなどのデータ転送方法をサポートしています。
ノード間のデフォルトのデータ通信方法は UDP 転送です。
データはコンテナから送信された後、ホストの仮想ネットワーク カードを介して仮想ネットワーク カードに転送されます. これは P2P 仮想ネットワーク カードであり、ネットワーク カードの反対側で flanneld サービスが監視されますdocker0/CNI.flannel0
Flannel は、各ノードのサブネット セグメントを詳細に記録する Etcd サービスを通じて、ノード間のルーティング テーブルを維持します。
送信元ホストのサービスは、元のデータ コンテンツ UDP をカプセル化し、独自のルーティング テーブルに従って宛先ノードのサービスに配信し、データが到着した後、解凍し、宛先ノードの仮想ネットワーク カードに直接入力しますflanneld。 、そして宛先ホストの仮想ネットワークカードに転送され、最後にローカルコンテナに経路を伝えて目的のコンテナに到達します。flanneldflannel0docker0/CNIdocker0/CNI
ETCDとフランネルの相関関係
- Flannel が割り当てることができる IP アドレス セグメント リソースの保存と管理
- ETCD で各 Pod の実際のアドレスを監視し、メモリ内に未払いの Pod ノードのルーティング テーブルを作成します。
要約する
この記事は前回の記事に続き、引き続き Pod の関連する知識ポイントを紹介します。さまざまな状況での Pod ネットワークのネットワーク通信方法を紹介します。CNI の概念の一部であり、この実験環境で使用される Flannel ネットワーク プラグインです。
後ろに書いてある
役に立つと思われる場合は、1 つのボタンと 3 つの連続したリンクでSiege Lion Baiyuをサポートし、この記事をより多くの友人と共有してください。あなたのシンプルなサポート、私の無限の創造力