Kubernetes の NodePort、LoadBalancer、Ingress を理解する

これら 3 つはクラスター内のサービスをクラスター外に公開できますが、それらの違いと、これらのコンポーネントを正しく使用する方法は何でしょうか。この記事があなたにインスピレーションを与えることを願っています。まず、NodePort と LoadBalancer は 2 種類の Kubernetes サービス コンポーネントを指していることを明確にしておきましょう。

正式に始める前に、サービスについて簡単に紹介する必要があります。サービスは、Pod のグループを抽象化したものです。クラスター内の IP を介してポッドに直接アクセスすることはできますが、ポッドは不安定であり、頻繁に停止する可能性があります。この時点で、クラスターは Pod (まったく新しい Pod) を再起動します。 IP アドレスが変更され、クライアントのアクセスに支障をきたします。この問題を解決するために、Kubernetes は Service コンポーネントを導入しました。 Pod が作成されてから手動で削除されるまで、その Pod 用に作成されたサービスへのアクセス方法は安定しており、アクセス IP は変更されません。クラスターの組み込み DNS サービスと組み合わせることで、クライアントは変更されていないサービス名またはサービス IP を使用してターゲット ポッドにアクセスできます。このサービスは、単純な負荷分散機能も実装しています。

この時点で、まだ解決されていない非常に重要な問題が残っています。Kubernetes クラスターの外部からクラスター内のサービスにアクセスするにはどうすればよいでしょうか?これがタイトルに挙げた 3 つのオブジェクトにつながり、以下で 1 つずつ紹介します。

ノードポート

Nodeport は 3 種類のサービスのうちの 1 つです (ExternalName は一般的に使用されないため、例外です)。他の 2 つは ClusterIP と LoadBalancer です。サービスが NodePort タイプで動作する場合、デフォルトでは各ノードはすべてのネットワーク インターフェイス上のポートを開き、クラスター内のサービスの要求を転送します。リクエストが届くと、ノードはそのリクエストをクラスター内のサービスに転送します。これにより問題が発生します。リクエストのターゲットノードがダウンしているか、その他の理由によりネットワークにアクセスできない可能性があります。 NodePort のもう 1 つの問題は、公開されるポートに制限があることです。デフォルトのポート範囲は 30,000 ～ 32,767 です。これにより、外部に公開できるサービスの数が制限されます。記録が容易ではないこれらのポートを使用してサービスにアクセスするのも頭痛の種です。これにより、次のサービス タイプである LoadBalancer が導入されます。

ロードバランサー

ほとんどのパブリック クラウド プラットフォームは、このタイプのサービスの作成をサポートしており、各サービスは複数のプロトコルと複数のポートをサポートし、単一の IP を使用してアクセスできます。内部サービスはクラスター外部からアクセスする必要があるため、この IP アドレスはパブリックであり、追加のコストが発生します。公開されているサービスが多数ある場合は、使用する際に注意が必要です。プライベート クラウド環境では、このタイプのサービスを作成することはできません。 NodePort タイプのサービスを作成し、HAproxy を使用してロード バランサーとして機能させることができます。これは、パブリック クラウド プラットフォームの LoadBalancer とほとんど変わりません。サービスには、ClusterIP、NodePort、LoadBalancer の 3 種類があります。後者は前者の強化版です。 NodePort タイプのサービスは ClusterIP タイプのサービスを作成し、LoadBalancer タイプのサービスは NodePort および ClusterIP タイプのサービスを作成します。サービス コンポーネントは、サービスの核となるオペレーティング システム内の iptables または ipvs に依存します。注意すべき点の 1 つは、NodePort タイプのサービスを使用する場合、リクエストはサービスのクラスター IP ではなく、実際の Pod に直接転送されることです (kube-proxy は iptables モードで動作します)。具体的な実装方法については、検索エンジンで「NodePort型サービスの仕組み」を検索してください。

イングレス

上記で紹介した内容は、いずれも主にネットワーク層の問題を解決するサービスを中心にした内容です。 Ingress の登場は、主にアプリケーション層の問題を解決するためです。 Ingress は実際にはリバース プロキシとして機能し、Nginx の機能と非常によく似ています。 Kubernetes で広く使用されている Nginx Ingress は、本質的には Nginx サービスです。 Ingress は、クラスター内のサービスを外部に公開する機能がないため、LoadBalancer タイプのサービスに依存しています。ここでは、Nginx Ingress を例に、その動作原理を紹介します。他の種類の Ingress については、公式ドキュメントを参照してください。

Nginx Ingress は主に Ingress Controller と Nginx の 2 つの部分で構成されます。コントローラーは、Watch を介して API サービスにアクセスし、Ingress リソースなどの関心のあるリソースの更新を収集し、Nginx を操作して、構成ファイル nginx.conf を変更し、証明書を更新し、Nginx を再起動するなどします。これは、Nginx マネージャーのようなものです。エンジニアはクラスターに指示を送り、コントローラーはエンジニアがAPIサーバーから送信した指示を受信して​​Nginxを操作します。これが一般的なワークフローです。

上の図には、「パブリック エンドポイント」コンポーネントがあり、これは LoadBalancer タイプのサービスを通じて実装できます。次の YAML スニペットは、Alibaba Cloud 上の実際の nginx-ingress サービスからのものです (IP アドレスとポートは匿名化されています)。

 ......
 仕様:
 クラスターIP : 172.14.13.67
 外部トラフィックポリシー: クラスター
ポート:
 - 名前: http
 ノードポート: 31800
 ポート: 80
 プロトコル: TCP
 ターゲットポート: 80
 - 名前: https
 ノードポート: 31700
 ポート: 443
 プロトコル: TCP
 ターゲットポート: 443
 セレクター:
 アプリ: イングレス- nginx
 セッションアフィニティ: なし
タイプ: ロードバランサー
状態：
 ロードバランサー:
 入口:
 - ip : 47.215.177.38 ​

クラスターが Ingress リソースをデプロイした後、クラスターに入るトラフィックの最初の停止地点は Nginx Ingress の Nginx サービスであり、HTTP レイヤーでの負荷分散と TLS 終了を実行します。

要約する

この記事では、NodePort および LoadBalancer タイプのサービスについて簡単に説明します。テスト環境で、クラスターからサービスをすばやく公開する必要がある場合は、NodePort タイプのサービスを使用できます。本番環境では、Alibaba Cloud や Tencent Cloud を利用すると LoadBalancer 型の Service を利用し、Ingress と連携することができます。このタイプのサービスがない場合は、NodePort タイプのサービスを使用して、負荷分散を実現するように Haproxy を構成することもできます。