Kubernetes クラスターのトラフィック露出に対するいくつかのソリューション

背景

Kubernetes をビジネスのオーケストレーションと管理に使用する場合、通常、Kubernetes にはビジネスの南北トラフィックにアクセスするためのソリューションがいくつかあります。この記事では、アクセス ソリューションについて簡単に紹介します。

交通アクセスソリューション

Kubernetes コミュニティは、クラスターにエントリ ポイントを追加することで、外部トラフィック管理の問題を解決します。

kube-proxy 経由のプロキシ

通常、最も単純なテスト環境または個人開発環境では、 kubectl port-forwardを使用して kube-proxy プロセスを開始し、コマンドが実行されるホスト ノードに内部サービスをプロキシできます。ホストにパブリック IP があり、転送リスニング ポートが0.0.0.0の場合、パブリック ネットワークからサービスにアクセスできます。このメソッドは、単一の Pod、Deployment、または Servcie をプロキシできます。

 $ kubectl ポート転送-h ​ ​
 1 つ以上のローカルポートをポッドに転送します。 このコマンドを使用するには、 ノードに「socat」がインストールされている必要があります。
 ポッドを選択するには、 deployment / mydeployment などのリソースタイプ/ 名前を使用します。 省略した場合、 リソースタイプはデフォルトで「pod」 になります。

 条件に一致するポッドが複数ある場合は、 ポッドが自動的に選択されます。 転送セッションが終了する
選択したポッドが終了し、 転送を再開するにはコマンドの再実行が必要になります。
 例:
 # ローカルでポート5000 と6000 をlisten し、 ポッド内のポート5000 と6000 との間でデータを転送します。
 kubectl ポート転送ポッド/ mypod 5000 6000 ​
 # ポート5000 と6000 をローカルでlisten し、 によって選択されたポッド内のポート5000 と6000 との間でデータを転送します。
 展開
kubectl ポート転送デプロイメント/ mydeployment 5000 6000 ​
 # ローカルでポート8443 をリッスンし、 選択されたポッド内の「https」という名前のサービスのポートのターゲットポートに転送します。
 サービス​
 kubectl ポート転送サービス/ myservice 8443 : https
 # ローカルではポート8888 をlistenし、 ポッド内の5000 に転送します
kubectl ポート転送ポッド/ mypod 8888 : 5000
 # すべてのアドレスのポート8888 をlisten し、 ポッド内の5000 に転送します
kubectl ポート転送-- アドレス0.0 .0 .0 pod / mypod 8888 : 5000
 # ローカルホストと選択したIP のポート8888 をlisten し、ポッドの5000 に転送します
kubectl ポート転送-- アドレスlocalhost 、 10.19 .21 .23 pod / mypod 8888 : 5000
 # ローカルでランダムなポートをlisten し、 ポッド内の5000 に転送します
kubectl ポート転送ポッド/ mypod : 5000

NodePort メソッド

2番目によく使用される方法は、NodePort メソッドです。 K8s のサービス タイプを NodePort メソッドに変更すると、ポート範囲 30000 ～ 32767 のホスト ポートが取得されます。同様に、ホストはパブリック IP を持っている場合はサービスを公開できますが、NodePort がホスト ポートを占有します。 1 つのサービスは 1 つの NodePort に対応します。この方法は 4 層のみであり、SSL 証明書をアンロードすることはできません。サービスが単一のノードの NodePort に転送される場合、高可用性は実現できません。通常、高可用性を実現するには、NodePort の前に負荷分散を備えた複数のバックエンド NodePort を追加する必要があります。

ロードバランサー

4層

レイヤー 4トラフィック転送の場合、LB ポートは 1 つのサービスにのみ対応し、サービス タイプは NodePort です。たとえば、次の図に示すように、LoadBalancer のポート 88 は、servcieA に対応するバックエンド NodePort のポート 32111 に転送されます。 LB 上のポート 8080 は、バックエンド NodePort のポート 32001 に転送されます。このソリューションでは、複数の NodePort を追加することで高可用性を実現できますが、レイヤー 4 であり SSL をアンロードできないため、対応する NodePort が LB 内のポートを占有する必要があります。

7階

第 7 層では、LB のドメイン名転送を使用して、複数のサービスに対応する 1 つのドメイン名ポートを実現できます。図に示すように、パスによれば、/cmp は NodePort の 32111 に対応し、/gateway は NodePort の 32000 ポートに対応します。これにより、高可用性を実現できるだけでなく、第 7 層での SSL アンロードも実現できます。

現在、一般的なパブリッククラウドの LB レベルにはレイヤー 4 とレイヤー 7 の機能があり、これらを組み合わせて使用​​することで柔軟なビジネス トラフィックの公開を実現できます。

イングレス

K8s には、異なるパスやその他の構成ルールに従って、K8 クラスター内の異なるサービスに単一のドメイン名転送を実装するための Ingress リソースがあります。ただし、ユーザー リクエストは、Ingress-nginx コントローラーのサービスの NodePort など、Ingress 実装コントローラーの NodePort にアクセスする必要があります。特定のビジネス ドメイン名には通常ポートがないため、通常はその前にポート転送 80/443 のレイヤーが必要です。

業界では、よく知られている Ingress (nginx/Ingress-traefik) など、Ingress Controller を実装するためのソリューションが数多く存在します。

ロードバランサー + イングレス

下の図に示すように、ポート 80/443 を ingress-provider の Service の NodePort に転送するために、前面に 4 層の LB があります。 K8s クラスター内には複数のサービスが構成されています。

Ingress-nginx の詳細な説明

上記のソリューションでは、Ingress が使用されています。 Nginx-ingress は、K8s イングレス リソースを実装するために Nginx によって公式に提供されるソリューションです。同時に、Kubernetes は Nginx をベースにした Ingress ソリューションも公式に提供しています。

Nginx Ingress は、リソース オブジェクト Ingress、Ingress コントローラー、Nginx の 3 つの部分で構成されます。 Ingress コントローラーの目的は、構成ファイル (nginx.conf) を構築することです。これは主に、構成ファイルの変更を検出した後に Nginx をリロードすることによって実現されますが、アップストリームが変更されたとき (アプリケーションのデプロイ時にエンドポイントを変更したとき) に Nginx をリロードするだけではありません。これは lua-nginx-module を使用して実装されます。

次の図は、Ingress-nginx の使用シナリオをよりよく理解するのに役立ちます。

この図には次の情報が表示されます。

• K8s クラスター。
• Kubernetes API を通じてクラスターを使用するクラスター ユーザー管理 (ユーザー A とユーザー B)。
• クライアント A とクライアント B は、それぞれのユーザーが展開したアプリケーション A と B に接続します。
• IC は、管理者によって名前空間 nginx-ingress のポッドにデプロイされ、ConfigMap nginx-ingress を介して構成されます。管理者は通常、冗長性のために少なくとも 2 つのポッドをデプロイします。 IC は Kubernetes API を使用して、クラスターで作成された最新の Ingress リソースを取得し、それらのリソースに基づいて NGINX を構成します。
• アプリケーション A は、ユーザー A によって 2 つのポッドを持つ名前空間 A にデプロイされます。アプリケーションをホスト A.example.com 経由でクライアント (クライアント A) に公開するために、ユーザー A はポータル A を作成します。
• ユーザー B は、名前空間 B にアプリケーション B のポッドをデプロイします。ホスト B.example.com を介してアプリケーションをクライアント (クライアント B) に公開するために、ユーザー B は VirtualServer B を作成します。
• 共通エンドポイントは IC ポッドの前にあります。これは通常、TCP ロード バランサ (クラウド、ソフトウェア、またはハードウェア)、またはそのようなロード バランサと NodePort サービスの組み合わせです。クライアント A と B は、パブリック エンドポイントを介してアプリケーションに接続します。

黄色と紫色の矢印はクライアント トラフィックに関連する接続を表し、黒色の矢印は Kubernetes API へのアクセスを表します。

簡潔にするために、デプロイメントやサービスなど、多くの必要な Kubernetes リソースは表示されませんが、管理者とユーザーはこれらのリソースを作成する必要があります。

他の

K8s では、Alibaba の ACK、Tencent の TKE、Huawei の CCE など、クラウドベンダーが CNI 対応の LB を提供することが多く、K8s クラスターを作成すると LB タイプのサービスが自動的に作成されます。しかし、自作や個人的なテストのシナリオでは、オープンソースのMetallb[1]が適切な選択肢となります。 K8s のネイティブな方法で LB タイプのサービス サポートを提供し、すぐに使用できます。もちろん、QingCloud TechnologyのKubeSphereチームによるオープンソースのロードバランサプラグインOpenELB[2]もあります。これは、物理マシン（ベアメタル）、エッジ（Edge）、プライベート環境向けに設計されたロードバランサプラグインです。 Kubernetes、K3s、KubeSphere の LB プラグインとして使用して、クラスターの外部に「LoadBalancer」タイプのサービスを公開できます。 2021 年 11 月に CNCF Sandbox ホスティングに参加し、ベアメタルまたはプライベート環境、特に物理マシンやエッジ クラスターに Kubernetes クラスターを展開するユーザーの悩みも解決します。 Kubernetes は LoadBalancer を提供しておらず、クラウドベースのロードバランサーと同じユーザーエクスペリエンスを提供します。

参考リンク

[1]Metallb: https://github.com/metallb/metallb.

[2]OpenELB: https://openelb.io/.