Trending keywords: security, cloud, container,

概 要

Kubernetes ネットワーキングとは

SHARE:

in this article:

Kubernetes ネットワーキングの仕組み Kubernetes で使用されるネットワーキングモデル Kubernetes ネットワーキングモデルの基本原理 Kubernetes では NAT が使用されるか？ Calico ネットワーキングとは まとめ

Content

Kubernetes ネットワーキングの仕組み
Kubernetes で使用されるネットワーキングモデル
Kubernetes ネットワーキングモデルの基本原理
Kubernetes では NAT が使用されるか？
Calico ネットワーキングとは
まとめ

Kubernetes クラスター内には、クラスター内のすべてのコンポーネントが相互に通信できるようにする Kubernetes ネットワーキングがあります。ネットワーキングは、世界中の多くのエンジニアが使用しているツールですが、その仕組みを実際に理解している人はほとんどいません。Kubernetes は、マシンのクラスター上で分散システムを実行するために開発されました。分散システムにより、ネットワーキングは実装に必要な中心的なコンポーネントになります。Kubernetes ネットワーキングモデルを理解すれば、Kubernetes で実行されるアプリケーションを最適な方法で実行、監視、トラブルシューティングできます。

Kubernetes ネットワーキングの仕組み

Kubernetes がどのように機能するかを理解するには、ネットワーキングの理解が不可欠です。ネットワーキングは、さまざまな方法でクラスター内で常に実行されています。以下は、Kubernetes クラスター内の 4 つの主な通信モードです: 

  1. Pod 間 
  2. Pod – サービス間 
  3. インターネット – サービス間 
  4. コンテナ間 

静的ポート割り当て

Kubernetes では、アプリケーション間でマシンを共有することで、コンピューティングリソースを最適化しますが、2 つのアプリケーションが同じネットワーキングポートを使用していないことが必要です。2 つのポートが交差しないように、ポートを手動で設定しても、この問題は解決できません。もぐらたたきゲームのように一日中設定し直すことになり、クラスターを完全に稼働させることはできません。別の方法として、動的ポート割り当てを使用することもできますが、この方法には特有の複雑さが伴います。 

動的ポート割り当て

動的ポート割り当てにより、すべてのアプリケーションがポートをフラグとして使用できるようになりますが、動的ポート番号を構成ブロックに挿入する方法をAPI サーバーが認識する必要があります。Kubernetes では、異なるネットワーキングのアプローチを採用しているため、相互通信にどのポートを探す必要があるかをサービスが認識する必要はありません。 

Kubernetes で使用されるネットワーキングモデル

IP/Pod モデル

Kubernetes では、すべての Pod に独自の IP アドレスが割り当てられるネットワーキングモデルを使用します。単一の Pod 内のすべてのコンテナは、同じネットワークネームスペースと IP アドレスを共有します。Pod と IP アドレスは一時的なものであることに注意してください。Pod が停止するか、何らかの理由で再起動する必要がある場合、新しい IP アドレスが割り当てられますが、これを管理する必要はなく、Pod 間の通信を作成したり、コンテナポートをホストポートにマップしたりする必要はありません。 

このネットワーキングモデルでは、ポートの割り当て、命名、負荷分散、移行に関して、Pod を仮想マシン（VM）のように扱うことができます。Kubernetes では、ネットワーキング実装の要件を次のように規定しています:  

  • すべての Pod は、ネットワークアドレス変換（NAT）を使用せずに他のすべての Pod と通信できます。
  • すべてのノードは、NAT なしですべての Pod と通信できます。

Kubernetes ネットワーキングモデルの基本原理

Kubernetes クラスター内のさまざまなネットワーキングコンポーネントについて詳しく見ていきましょう。

Pod 間ネットワーキング

Kubernetes では、各 Pod にそれぞれ独自の IP アドレスが割り当てられ、独自のネットワークネームスペースがあります。Pod は、IP アドレス経由で相互に通信できます。このモデルは VM に非常に似ており、各 Pod はネットワークポートを公開し、IP アドレスとポート番号によってネットワーク上の他の VM をアドレス指定できます。 

Pod 間ネットワーキング – 同じノードの Pod

Pod が稼働するために実行されているノードを考慮せずに、Pod 間の通信を完全に理解することはできません。この通信は、Pod が実行されているノードで仮想イーサネットデバイス経由で実行されます。Pod が別のノードの IP アドレスにリクエストを送信すると、ノードの仮想イーサネットデバイスをトンネリングします。この接続には両面があります。Pod 側の名前は eth0、仮想コンポーネントであるノード側の名前は vethx（仮想イーサネット）で、その後にインデックス 0 から始まる数値が続きます。  

この接続は、ネットワークブリッジを使用して 2 つのネットワークを接続することで可能になります。Pod からのリクエストがブリッジに到達すると、ブリッジでは、同じノード経由でアクセスできるすべての Pod に、リクエストを処理するための正しい IP アドレスがあるかどうかを判断し、存在する場合は、同じノードを使用している 2 つの Pod 間でネットワーク接続が確立されます。

Pod 間ネットワーキング – 異なるノードの Pod

他の種類の Pod 間通信では、Pod は異なるノードにあります。このタイプの通信にネットワークブリッジ方式を使用しようとすると、失敗します。ただし、これは、クラスターに使用しているクラウドプロバイダとネットワークプラグインによって異なる場合があることに注意してください。 

異なるノード上の Pod 間の通信操作は、クラスターレベルで実行する必要があります。各クラスターには、IP アドレス範囲をノードにマップするテーブルがあります。これらのノードの Pod には、それらの範囲から割り当てられる IP アドレスがあります。次の図に示すように、Kubernetes はノード 1 とノード 2 の Pod にアドレスを割り当てます: 

各ノードには、クラスターの他のノードと通信するためのそれぞれ独自の方法があります。この点からも、Pod 間の通信は、同じノードの Pod が相互に通信する方法と似ています。

Pod – サービス間ネットワーキング

Pod は一時的なものであるため、Pod の IP アドレスは変化する可能性があります。別の Pod と直接通信するように Pod を構成することもできますが、バックエンドの IP アドレスを追跡する必要があり、Pod が再起動されるたびに IP アドレスが変化する場合は、注意が必要です。この問題を解決するには、Service と呼ばれる Kubernetes リソースを使用して 2 つの Pod をリンクします。 

Kubernetes Service を使用すると、clusterIP と呼ばれる単一の一意の IP アドレスを Pod のグループに割り当てることができます。単一の clusterIP エンドポイントにリクエストを実行できます。サービスは Service に属する Pod にリクエストをプロキシします。 

この通信は、Kubernetes がすべてのノード内で実行する小さなプロセスである kube-proxy 経由で実行されます。このプロセスは、Service の仮想 IP アドレスを Pod IP アドレスのグループにマップします。kube-proxy プロセスが Service の仮想 IP を Pod の IP にマップすると、リクエストプロセスは上記のように実行されます。

 

インターネット – サービス間ネットワーキング

外部とやり取りできるアプリケーションを実行できる Kubernetes クラスターを管理するには、インターネット接続が不可欠です。1）Kubernetes Service からインターネット、2）インターネットから Kubernetes Service のトラフィックを取得できるようにする必要があります。

クラウドプロバイダでは、このタイプの通信を開始するために必要な NAT ゲートウェイを提供しています。NAT ゲートウェイでは、公開 IP アドレスを持たないクラウドリソースが着信インターネット接続に公開されることなく、インターネットにアクセスできます。 

例として、AWS クラウド プロバイダを使用してみましょう。AWS では、Kubernetes クラスターは VPC 内で実行されます。すべてのノードには、Kubernetes クラスター内からアクセスできるプライベート IP アドレスが割り当てられます。クラスターの外部からトラフィックにアクセスできるようにするには、インターネットゲートウェイを VPC にアタッチする必要があります。 

外部アクセスの設定はイングレスとエグレスの両方でサポートされます。 

  • エグレスでは、トラフィックをノードから外部接続にルーティングします。 
  • イングレスでは、外部クライアントが Kubernetes Services と通信できるようにします。

エグレスがノードから外部アプリケーションにトラフィックを正常にルーティングするには、インターネットゲートウェイが不可欠です。ゲートウェイは、パブリッククラウド内でホストされる安全で分離されたプライベートクラウドコンピューティング環境である仮想プライベートクラウド（VPC）にアタッチされます。 

イングレスは、事前定義された一連のルールに基づいて、一部の接続を許可し、他の接続が Kubernetes Services と通信できないようにブロックできます。ルールは、クラスターと Services へのアクセスを許可または拒否する IP テーブルとして確立されます。 

コンテナ間ネットワーキング

コンテナは、同じ Pod を共有し、同じ IP アドレスを共有するため、別のコンテナと通信できます。コンテナは、localhost をアドレス指定することで相互に通信します。コンテナが同じ Pod 内の別のコンテナと通信する必要がある場合は、アドレス localhost:8080 を使用してポート 8080 で通信できます。 

Kubernetes では NAT が使用されるか？

Kubernetes では、ネットワークアドレス変換（NAT）を使用しません。クラスター内のすべての Pod は他の Pod と通信できます。また、すべてのノードは NAT を使用せずにクラスター内のすべての Pod と通信できます。

Calico ネットワーキングとは

Calico は、2016 年に開発されたオープンソースのネットワーキングとネットワークセキュリティツールです。その人気の高まりにより、Kubernetes ネットワーキングスペースのリーダーになっています。 

Calico は、マシン上のワークロード間のネットワーク接続を提供し、ワークロード間にネットワークセキュリティポリシーを適用します。Calico には、プラグインを使用して幅広いデプロイオプションをサポートする柔軟なアーキテクチャがあります。

Calico CNI（Container Network Interface）

Calico は、独自の Container Network Interface（CNI）プラグイン、クラウドプロバイダ統合、多数のサードパーティ CNI プラグインで利用できます。Calico CNI は、仮想イーサネットデバイスペア（veth ペア）を使用して、Pod をホストネットワークネームスペースの L3 ルーティングに接続します。OSI モデルの L2 レイヤーから操作している場合、ネットワークブリッジにさらなるオーバーヘッドが発生しますが、L3 アーキテクチャを使用すると、これらを回避できます。 

詳細については、こちらの GitHub リポジトリを参照してください。

まとめ

Kubernetes のネットワーキングを理解するのは難しいかもしれませんが、ここまで、Kubernetes クラスター内部のさまざまな通信手段について明確に理解できたと思いますので、これらを活用して、職場での課題に自信を持って取り組んでください。