Kubernetes クラスターの外部の Pod でサービスを公開するにはどうすればよいですか?

Kubernetes クラスターを使用してサービスを実行し、サービスを提供するアプリケーションは Pod で実行されます。クラスター外のアプリケーションにアクセスするには 2 つの方法があります。1 つは Pod 自体で実装することです。もう 1 つは、他のコンポーネントに依存することです。

• ポッド自体がサービスを公開する

1. ホストネットワーク:true

Pod の yaml 定義ファイルでこのオプションを構成すると、Pod はホストのネットワーク スタックを使用します。これは、ホスト上で実行されているサービスに直接アクセスするのと変わりません。 Podで実行されているサービスにアクセスするには、「ホストIP+ポート」方式を使用します。たとえば、次のPod定義ファイルのように。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: nginx
 仕様:
 ホストネットワーク: true
 コンテナ:
 - 名前: nginx
 イメージ: nginx : 1.23.1
 ポート:
 - コンテナポート: 80

実行後、コンテナが動作しているホストにログインすると、ポート 80 でリッスンしているサービスがあることがわかります。

ホストマシンのポート80をリッスンする

アクセスに問題はありません（192.168.52.132 はホストマシンの IP です）。

サービスアクセス

Pod が再起動されると、別のホストにスケジュールされる可能性があります。この場合、アクセス IP も変更する必要があり、ポートの競合を防ぐ必要があります。サービスがすでにホストのポートを占有している場合、新しい Pod は起動できません。

2. ホストポート

上記の Pod の yaml ファイルを少し変更し、最後の行を追加して、「hostNetwork: true」を削除します。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: nginx
 仕様:
 コンテナ:
 - 名前: nginx
 イメージ: nginx : 1.23.1
 ポート:
 - コンテナポート: 80
 ホストポート: 8080

最初の方法と比較すると、外部に公開されるポートを柔軟に構成できます。注意すべき点は、「hostPort」モードでは、サービスはコンテナのネットワーク スタックをリッスンし、ホストはファイアウォール上でメッセージを転送することです。したがって、ホストのポート 8080 を照会すると、リッスンしているサービスがないことがわかります。

リスニングポート

ファイアウォールをチェックして、ホストにポート転送があることを確認します。

ポッドIP

ホスト上でDNATを実行する

この方法には最初の方法と同じ欠点があります。コンテナの再起動は他のホストにスケジュールされる場合があります。 Pod によって公開されるポートが手動で調整されない限り、同じ Pod をホスト上で実行することはできません。

• 依存コンポーネントはサービスを公開する

上記の 2 つの方法は、Pod 独自のリソース定義に依存して、クラスター外部にサービスを公開します。次の 2 つの方法は、サービスを公開するために他の Kubernetes リソースに依存します。

3. ノードポート

「NodePort」は、Kubernetes の「Service」リソースのプロパティです。デフォルトでは、「サービス」はクラスター内でのサービス アクセスを実装します。 「NodePort」を追加すると、クラスター外からサービスにアクセスできるようになります。デフォルトでは、Kubernetes はホスト マシンのポート 30000 ～ 32767 から 1 つのポートを選択してアクセスを提供しますが、これは手動で指定できます。

サンプルの yaml ファイル。

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: nginx
 ラベル:
 名前: nginx
 仕様:
 コンテナ:
 - 名前: nginx
 イメージ: nginx : 1.23.1
 ポート:
 - コンテナポート: 80
 ---
 種類: サービス
APIバージョン: v1
 メタデータ:
 名前: nginx
 仕様:
 タイプ: NodePort
 ポート:
 - ポート: 8080
 ノードポート: 30000
 ターゲットポート: 80
 セレクター:
 名前: nginx

yaml ファイルを適用すると、「ホスト IP + 30000」を介してクラスター外のサービスにアクセスできるようになります。

nodePort を使用してサービスにアクセスする

高可用性を実現するために、haproxy をデプロイし、バックエンドを複数のクラスター ホストによって公開されるサービスにすることで、可用性を向上させることができます。 「nodePort」サービスの動作原理は次のとおりです。トラフィックがホストによって公開されているポート 30000 に入ると、「サービス」の「クラスター IP + ポート」に転送され、次に Iptables (実装によっては ipvs の場合もあります) を介して対応するポッドに転送されます。

4. イングレス

Ingress を使用してサービスを公開する方法は、実稼働環境でより一般的に使用されます。 Ingress API リソース オブジェクトは Kubernetes に組み込まれていますが、このオブジェクトを使用するには、「コントローラー」をインストールする必要があります。選択できるサードパーティの「コントローラー」は多数あります。ここでは、「Nginx Ingress コントローラー」を選択します。 (インストールプロセスは含まれません)。

yamlの例:

 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前空間: テスト
名前: nginx
 ラベル:
 名前: nginx
 仕様:
 コンテナ:
 - 名前: nginx
 イメージ: nginx : 1.23.1
 ポート:
 - コンテナポート: 80
 ---
 種類: サービス
APIバージョン: v1
 メタデータ:
 名前空間: テスト
名前: nginx
 仕様:
 ポート:
 - ポート: 8080
 ターゲットポート: 80
 セレクター:
 名前: nginx
 ---
 apiバージョン: ネットワーク。 k8s 。 io / v1
 種類: イングレス
メタデータ:
 名前空間: テスト
名前: nginx
 注釈:
 Kubernetes 。 io / イングレス。 クラス: "nginx"
 仕様:
 ルール:
 - ホスト: nginx 。 例。 cc
 http://www.google.com/dp ...
 パス:
 - パスタイプ: プレフィックス
パス： "/"
 バックエンド:
 サービス：
 名前: nginx
 ポート:
 番号: 8080

私のテスト環境の Ingress Controller は nodePort モードで実行されるため、公開される HTTP ポートは 31763 です。

イングレスコントローラによって公開されるポート

デプロイされたサービスにアクセスするには、Ingress リソース定義で構成されたドメイン名を使用します。

アクセスサービス

実稼働環境では、"hostPort" を使用してポート 80 でリッスンするなど、Ingress コントローラー ネットワークの動作モードを変更できます。

注目すべき点は、トラフィックをサービスのクラスター IP に送信する「nodePort」とは異なり、Ingress コントローラーはクラスター外部のユーザーからのトラフィックをポッドがリッスンするポートに直接送信するため、はるかに効率的であるということです。

要約する

上記で紹介した 4 つのサービス公開方法の他に、クラウドベンダーに依存する「LoadBalancer」を使用することもできます。 Kubernetes クラスターがパブリック クラウドにデプロイされている場合は、実際の状況に応じて構成できます。