Kubernetesネットワーキングとは

ネットワークは複雑で、ポッド、ノード、コンテナ、サービスなどの内部と、Kubernetes クラスターの外部トラフィックのように外部に存在するすべての主要コンポーネント間の通信が必要です。

これらのコンポーネントは、次の4つの異なるネットワーク方式で通信を行っています。

1. コンテナ間のネットワーキング。

2. ポッド間のネットワーキング。

3. ポッドからサービスへのネットワーキング。

4. 外部からサービスへのネットワーキング。

Kubernetesという名前は、操舵手またはパイロットを意味するギリシャ語に由来しています。Googleの内部コンテナ・オーケストレーション・プラットフォームであるBorgをベースとするKubernetesは、2014年にオープンソース・ツールとして一般に公開されました。

同年、Google社はKubernetesを、オープンソースでベンダー・ニュートラルなクラウド・ネイティブ・コンピューティングのハブである、Cloud Native Computing Foundationに寄付しました。それ以来、Kubernetesは、コンテナベースのワークロードの実行に世界で最も広く使用されるコンテナ・オーケストレーションツールになりました。

Kubernetes（k8sまたはkubeとも呼ばれます）の設計における明確な目的は、コンテナ（コードとその依存関係をすべてパッケージ化したソフトウェアの標準単位）管理の自動化です。このオーケストレーション・ツールは、オンプレミス、プライベートクラウド、パブリッククラウド、ハイブリッドクラウドなど、どのようなインフラ環境でも迅速かつ確実に稼働する点で高く評価されています。

物理ハードウェアを仮想化する仮想マシン（VM）とは異なり、コンテナはオペレーティング・システム（Linux®やWindowsなど）を仮想化します。各コンテナには、アプリケーションのライブラリと依存関係のみが保持されます。コンテナはホストと同じオペレーティング・システム・カーネルを使用するため、軽量で高速、かつポータブルであると考えられています。

Kubernetesとそのサービス、サポート、ツールのエコシステムは、最新のクラウドインフラとアプリケーションのモダナイゼーションの基盤となっています。Amazon Web Services（AWS）、Google、Microsoft、IBM®、Red Hat®など、主要なクラウドプロバイダーはすべて、Platform-as-a-Service（PaaS）とInfrastructure-as-a-Service（IaaS）の機能を強化するために、自社のクラウドプラットフォームにKubernetesを統合しています。

Kubernetesアーキテクチャーは次の基本コンポーネントで構成されます。

その他のKubernetesコンポーネントには、次のものがあります。

デプロイメント：Kubernetesにおけるデプロイメントは、一連のポッドを管理して、アプリケーションのワークロードを実行します。デプロイメントにより、クラスター上で稼働すべきポッドのレプリカの数が特定されます。あるポッドが機能を停止すると、デプロイメントによって新しいポッドが作成されます。

この重要な機能は、レプリカ・ポッドの数を拡大し、ローリング・コードを更新し、可用性を維持するのに役立ちます。デプロイメントの実行には、Kubernetes固有のコマンドライン・ツールであるkubectlを使用します。

サービス：Kubernetesサービスは、ポッドの論理セットとそれらへのアクセス方法を定義する抽象化レイヤーです。サービスにより、クラスター内の 1 つ以上のポッドで実行されるネットワーク・アプリケーションが明らかになるほか、ポッドの負荷分散を確保する抽象的な方法がわかります。

アプリケーション・プログラミング・インターフェース（API）サーバー：KubernetesのAPIサーバーは、Kubernetes API（Kubernetesクラスターの管理、作成、構成に使用されるインターフェース）を公開しており、すべてのコマンドとクエリのエントリー・ポイントとして機能します。

基本的なコンピューター・ネットワーキングは、ケーブル（有線）またはWiFiのいずれかで2つ以上のコンピューター・デバイスを接続し、データの共有やリソースの交換を行うことを主とします。

物理ネットワークでは、物理サーバーを物理ネットワーク機器（スイッチ、ルーター、イーサネット・ケーブルなど）に接続して、インターネットに接続します。

仮想ネットワーキング、ソフトウェア定義ネットワーク（SDN）では、仮想イーサネット・デバイスや仮想インターフェースなどのコンポーネントがベアメタル・サーバーや仮想マシンにインストールされ、インターネットに接続されます。Kubernetesのデプロイメントでは、SDNを使用してクラスター間のネットワーク通信を構成および管理します。

Kubernetesネットワーキングをさらに深く掘り下げる前に、基本的なネットワーク用語を確認しましょう。

ネットワーク・ホスト: ネットワーク・ホストは、ネットワークに接続され、ネットワーク上の他のホストまたはノードに情報、アプリケーション、またはサービスを提供するコンピューターです。

インターネット・プロトコル (IP) アドレス: IP アドレスは、通信にIPを使用するネットワークに接続されているすべてのデバイスに割り当てられる一意の番号です。この番号によって、デバイスのホスト・ネットワークと、そのホスト・ネットワーク上のデバイスの位置が識別されます。

ローカルホスト: ローカルホストは、プライベートIPアドレスとして機能するデフォルトのホスト名で、使用するコンピューターまたはデバイスを直接指します。

ポート: ポートは、ネットワーク・デバイス間の特定の接続を識別するものです。各ポートは番号によって識別されます。コンピュータはポート番号を使用して、どのアプリケーション、サービス、プロセスが特定のメッセージを受信するかを決定します。

ネットワークアドレス変換 (NAT): NATは、内部またはプライベートのアドレスを、パブリックまたはグローバルにルーティング可能なIPアドレスに変更し、安全なインターネット・アクセスを実現します。NATを使用すると、1つの一意のIPアドレスでコンピューティング・デバイスのグループ全体を表すことができます。

ノード・エージェント: ノード・エージェントは、ホスト・システム上のアプリケーション・サーバーを監視し、管理上の要求をサーバーにルーティングする管理エージェントです。

ネットワーク名前空間: ネットワーク名前空間は、ネットワーク・インターフェースと、ルーティング・テーブルによる指示の集合で、ネットワーク・デバイスを分離する働きをします。

プロキシまたはプロキシ・サーバー: プロキシは、ユーザーとインターネットの間にゲートウェイを設けます。

Kubernetesは、マシンのクラスター全体に分散されたネットワーク・プレーンで分散システムを実行するために作成されました。Kubernetesクラスター・ネットワーキングは、コンポーネント間の相互接続性を提供するだけでなく、ソフトウェア定義型ネットワーキングにより、データを自由かつ効率的に移動できるシームレスな環境を構築します。

Kubernetesネットワーキングのもう1つの大きな特徴は、フラットなネットワーク構造です。すべてのコンポーネントが、他のハードウェアに依存せずに接続できることを指します。Kubernetesでは、クラスター内のすべてのポッドは、それがどのノードで動作しているかに関係なく、他のすべてのポッドと通信できます。フラット・ネットワークによって効率的にリソースを共有することができ、動的ポート割り当ての必要がなくなります。

総じて言うと、Kubernetesネットワーキングによって複雑なものが抽象化され、開発者とオペレーターは、複雑なネットワーク構成に対応するのではなく、アプリケーションの構築と保守に集中できるようになります。

Kubernetesは、分散環境全体にわたるコンテナ化されたアプリケーションのオーケストレーションにおける課題に対処するのに役立つネットワーキング・モデルを提供します。各ノードのコンテナ・ランタイムはネットワーク・モデルを実装しており、次のルールに従います。

各ポッドには独自のIPアドレスがあり、クラスター内でルーティングできます。この機能により、ポッドとマッピングポート間のリンクを作成する必要がなくなります。

各ポッドには独自のIPアドレスがあるため、NATは必要ありません。すべてのポッドが、NATを使用せずにクラスター内の他のあらゆるポッドと通信できます。

ノード上のエージェント (各ノードで実行されるプライマリ・ノード・エージェントであるkubeletなど) は、そのノード上のすべてのポッドと通信できます。

Kubernetesネットワーキング・モデルは、次に述べる、Kubernetes通信における4つの基本タイプに適用されます。

コンテナは、Kubernetesネットワークの最小単位です。基本的なネットワーク構成では、コンテナはローカルホストを介して単一のポッド内で通信します。

この通信ができるのは、同じポッド内のコンテナが同じネットワーク名前空間（ストレージ、IPアドレス、ポート空間などのネットワーキング・リソースを含む）を共有しているためです。

ポッド間の通信には、同じノード上のポッド間の通信と、異なるノード上のポッド間の通信も含まれます。Kubernetesクラスター内の各ポッドには独自の一意のIPアドレスがあり、ポッドがどのノードに存在していても、ポッド間の直接通信を行うことができます。

さらに、各Kubernetesクラスターは、ポッドのIPアドレスに加えて、ドメインネーム・システム・サービス（DNSサービス）を自動的に提供します。DNSサービスでは、ポッドおよびサービスに名前が割り当てられ、管理者にとって簡単で読みやすい名前が作成されます。これにより、サービス検出のための軽量のメカニズムがもたらされます。

Kubernetesのサービスとは、ポッドの論理セットを定義し、それらのポッドに対する外部トラフィックの公開、負荷分散、およびサービス検出を可能にする抽象化を行うことです。このサービスは、ポッドからサービスへの通信と外部からサービスへの通信の両方を促進します。

Kubernetesネットワーキング・モデルによると、ポッドのIPアドレスは一時的なものです。したがって、ポッドがクラッシュするか削除され、その場所に新しいポッドが作成された場合、新しいポッドには新しいIPアドレスが割り当てられる可能性が高くなります。

ポッドからサービスへの通信におけるClusterIPは、一連のポッドに安定した仮想IP アドレスを提供する、サービスの一種です。この内部IPはクラスター内のみ接続可能で、ポッドとサービス間の内部通信に使用できます。

kube-proxyはクラスター内のすべてのノードにインストールされており、ホスト上のネットワーク・ルールを維持し、サービスとポッドの変更を監視します。ポッドが作成または破棄されると、kube-proxyは IPtables（トラフィックのルーティング用のLinuxカーネル・ファイアウォールに関するルールの作成に使用されるユーティリティー・プログラム）を更新してその変更を反映し、サービスIPに送信されたトラフィックが正しくルーティングされるようにします。

外部からサービスへのネットワーキングとは、外部サービスやデータベースなどのサービスを公開し、Kubernetesクラスターの外部からアクセスすることを指します。

Kubernetesでは、クラスターへの外部トラフィックを促進する、数種類のサービスを利用できます。

ClusterIP: ClusterIPは内部通信用のデフォルトのKubernetesサービスですが、外部トラフィックも、kube-proxy経由でアクセスできます。ClusterIPは、ノートPC上のサービスにアクセスするとき、またはサービスをデバッグするときに役立ちます。

NodePort: NodePortは、各ノードのIP上の静的ポートでサービスを公開し、クラスターの外部からサービスにアクセスできるようにします。NodePort は、外部からサービスへのネットワーキングを行う最も基本的な方法であり、アプリへのパブリック・アクセスのテストなど、テスト目的でよく使用されます。

LoadBalancer: 外部サービス・ネットワーキングの標準であるLoadBalancerは、クラウド・プロバイダーの負荷分散装置を使用してサービスを外部に公開し、サービスにパブリックIPアドレスを割り当てます。外部の負荷分散装置からのトラフィックは、バックエンド・ポッドに転送されます。

ExternalName: この外部ネーム・サービスを使用すると、DNSクラスターに公開せずに、DNS名による外部サービスへのアクセスが可能になります。このタイプのサービスは、クラスター内に属さないメッセージング・サービスなどの外部サービスに、安定したDNS名を提供するのに役立ちます。

Ingress: Kubernetes ingressは、クラスター内のサービスへの外部アクセスに関するルーティング・ルールを集めたものです。Ingress Controllerは、Kubernetesサービスと外部サービスの間のネットワーク・ブリッジとして機能する負荷分散装置です。

Kubernetesネットワーク・ポリシーは、Kubernetesネットワーキングにおいて重要な役割を持つアプリケーション構造です。これらのポリシーを取り入れることで、管理者と開発者は、ポッド同士の通信方法や、ポッドと他のネットワーク・エンドポイントとの通信方法を指定するルールを定義できます。

ネットワーク・ポリシーは、Kubernetes Network Policies API を使用して適用され、次の基本コンポーネントで構成されます。

ポッド・セレクター: ポッド・セレクターは、ラベルとセレクターに基づき、ポリシーが適用されるポッドを指定します。

Ingress: Ingressは、ポッドへの受信トラフィックのルールを定義します。

Egress: Egressは、ポッドからの発信トラフィックのルールを定義します。

Kubernetesネットワーク・ポリシーは、相互に通信できるポッドを制御するルールを定義することで、セキュリティー・ポリシーの定義と管理に貢献します。これにより、不正アクセスや悪意のある攻撃を防止できます。

また、ネットワーク・ポリシーは、ポッドとサービス間の分離も保証し、それらのポッドまたはサービスのみが許可されたピアのセットと通信できるようにします。たとえば、DevOpsや他のチームが同じKubernetesクラスターを共有しながら異なるプロジェクトに取り組んでいるようなマルチテナントの状況では、分離が重要です。

特定のコンプライアンス要件がある企業の場合、ネットワーク・ポリシーは、ネットワーク・アクセス制御の具体化と徹底に役立ちます。これにより、規制基準を満たし、クラスターを組織のポリシーに確実に準拠させることができます。

Container Network Interface (CNI) は、Kubernetesネットワーキングに関連するもう 1 つの重要な機能です。Cloud Native Computing Foundationによって作成・保守され、KubernetesやRedHat OpenShift、Apache Mesosなどのコンテナ・ランタイムで使用されているCNIは、ネットワーク・プラグインによってどのようにコンテナ・ネットワーキングを実現すべきかを定義する、標準化された仕様および一連のAPIです。

CNIプラグインは、IPアドレスの割り当て、ネットワーク名前空間の作成、ネットワーク・ルートの設定などを行い、それによって、同じノード内と異なるノード間の両方でポッド間の通信を実現します。

KubernetesにはデフォルトのCNIが備わっていますが、Calico、Flannel、Weave などの多数のサードパーティCNIプラグインは、コンテナベースのネットワーキング環境で構成とセキュリティーに対処するように設計されています。

オーバーレイ・ネットワークやダイレクト・ルーティングなど、ネットワーキングの機能やアプローチはそれぞれ異なる可能性がありますが、いずれもKubernetesと互換性のあるCNI仕様を遵守しています。

Kubernetesのご利用、またはKubernetesおよびKubernetesエコシステム・ツールに関する既存のスキルの強化をご希望のお客様は、これらのチュートリアルのいずれかをお試しください。

• Kubernetesチュートリアル：認定付きのハンズオン・ラボ
• IBM DeveloperにおけるKubernetesのチュートリアル
• Kubernetesの8つのヒントとコツ
• Kubernetesを利用してIBM Cloud®にマイクロサービス・アプリをデプロイ