Kubernetes の 3 つの外部アクセス方法: NodePort、LoadBalancer、Ingress

最近、何人かの学生から NodePort、LoadBalancer、Ingress の違いについて質問を受けました。どちらも外部クラスタートラフィックをクラスターにインポートする方法ですが、実装方法は異なります。それぞれの仕組みと、どのように選択できるかを見てみましょう。

注: ここで説明する内容はすべて Google Kubernetes Engine に基づいています。 minikube やその他のツールを使用してオンプレミスモードで他のクラウド上で実行する場合、対応する操作が少し異なる場合があります。あまり技術的な詳細には立ち入りませんが、もっと詳しく知りたい場合は、公式ドキュメント[1]が素晴らしいリソースになります。

[[225771]]

クラスターIP

ClusterIP サービスは Kubernetes のデフォルトサービスです。クラスター内でサービスが提供され、クラスター内の他のアプリケーションがそのサービスにアクセスできるようになります。クラスターの外部からはアクセスできません。

ClusterIP サービスの YAML ファイルは次のようになります。

 APIバージョン: v1
種類: サービス
メタデータ:
名前: my-internal-service
セレクタ：
  アプリ: 私のアプリ
仕様:
  タイプ: ClusterIP
  ポート:
  -名前: http
    ポート: 80
    ターゲットポート: 80
    プロトコル: TCP

ClusterIP サービスがインターネットからアクセスできない場合、なぜそれについて議論するのでしょうか?それは、Kubernetes プロキシモードを通じてサービスにアクセスできるからです。

Kubernetes プロキシモードを開始します。

 $ kubectl プロキシ--port=8080

次のパターンを使用して、Kubernetes API を介してこのサービスにアクセスできます。

 http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE- NAME >:<PORT- NAME >/

上記で定義したサービスにアクセスするには、次のアドレスを使用できます。

 http://localhost:8080/api/v1/proxy/namespaces/デフォルト/services/my-internal-service:http/

このアプローチはいつ使用すればよいですか?

シナリオによっては、Kubernetes プロキシモードを使用してサービスにアクセスする必要があります。

何らかの理由で、サービスをデバッグしたり、ラップトップから直接サービスにアクセスしたりする必要があります。
社内通信、社内ダッシュボードの表示などを可能にします。

このアプローチでは、認証されていないユーザーとして kubectl を実行する必要があるため、この方法でサービスをインターネットに公開したり、本番環境で使用したりすることはできません。

ノードポート

NodePort サービスは、外部トラフィックをサービスに誘導する最も原始的な方法です。 NodePort は、その名前が示すように、すべてのノード (仮想マシン) で特定のポートを開き、このポートに送信されたトラフィックは対応するサービスに転送されます。

NodePort サービスの YAML ファイルは次のようになります。

 APIバージョン: v1
種類: サービス
メタデータ:
名前: my-nodeport-service
セレクタ：
  アプリ: 私のアプリ
仕様:
  タイプ: NodePort
  ポート:
  -名前: http
    ポート: 80
    ターゲットポート: 80
    ノードポート: 30036
    プロトコル: TCP

NodePort サービスは、通常の「ClusterIP」サービスとは主に 2 つの点で異なります。 ***、そのタイプは「NodePort」です。ノード上で開いているポート値を指定する、nodePort と呼ばれる追加のポートがあります。このポートを指定しない場合は、システムがランダムにポートを選択します。 thockin がコメントで述べたように、ユーザーが利用可能なポートを自分で選択するのはコストがかかりすぎるため、ほとんどの場合、Kubernetes にポートを選択させる必要があります。

このアプローチはいつ使用すればよいですか?

このアプローチにはいくつかの欠点があります。
各ポートは1つのサービスのみに対応します
ポート範囲は30000～32767のみです

ノード/VMのIPアドレスが変更された場合、この状況に対処できる必要があります。

上記の理由から、本番環境でこの方法でサービスを公開することはお勧めしません。実行しているサービスが常時可用性を必要としない場合、またはコストが重視される場合は、このアプローチを使用できます。このようなアプリの最も良い例は、デモアプリや一時的なアプリです。

ロードバランサー

LoadBalancer サービスは、サービスをインターネットに公開するための標準的な方法です。 GKEでは、このアプローチによりネットワークロードバランサ[2]が起動され、単一のIPアドレスが割り当てられ、すべてのトラフィックがサービスに転送されます。

このアプローチはいつ使用すればよいですか?

サービスを直接公開する場合、これがデフォルトになります。指定したポートへのすべてのトラフィックは、対応するサービスに転送されます。フィルターやルーティングなどはありません。つまり、HTTP、TCP、UDP、Websockets、gRPC など、ほぼあらゆる種類のトラフィックをサービスに送信できます。

このアプローチの最大の欠点は、LoadBalancer で公開される各サービスに独自の IP アドレスが割り当てられ、使用される LoadBalancer ごとに料金が発生するため、非常にコストがかかることです。

イングレス

上記のすべての例とは異なり、Ingress は実際にはサービスの種類ではありません。代わりに、複数のサービスの前に配置され、「スマートルーター」またはクラスターエントリポイントとして機能します。

Ingress ではさまざまなことを実行でき、Ingress コントローラーの種類によって機能が異なります。

GKEのデフォルトのイングレスコントローラはHTTP(S)ロードバランサ[3]を起動します。パスまたはサブドメインに基づいてトラフィックをバックエンドサービスにルーティングできます。たとえば、ドメイン foo.yourdomain.com 宛てのすべてのトラフィックを foo サービスに転送し、パス yourdomain.com/bar/path のトラフィックを bar サービスに転送できます。

L7 HTTPロードバランサ[4]を使用してGKE上で生成されるIngressオブジェクトのYAMLファイルは、次のようになります。

 apiバージョン: extensions/v1beta1
種類: イングレス
メタデータ:
名前: my-ingress
仕様:
  バックエンド:
    サービス名: その他
    サービスポート: 8080
  ルール:
  - ホスト: foo.mydomain.com
    http:
      パス:
      - バックエンド:
          サービス名: foo
          サービスポート: 8080
  - ホスト: mydomain.com
    http:
      パス:
      - パス: /bar/*
        バックエンド:
          サービス名: バー
          サービスポート: 8080

このアプローチはいつ使用すればよいですか?

Ingress はおそらくサービスを公開する最も大規模な方法ですが、最も複雑でもあります。 Ingress コントローラには、Google Cloud Load Balancer、Nginx、Contour、Istio など、さまざまな種類があります。また、cert-manager[5]などのさまざまなプラグインがあり、サービスにSSL証明書を自動的に提供できます。

Ingress は、同じ IP アドレスを使用して複数のサービスを公開し、それらすべてが同じレイヤー 7 プロトコル (通常は HTTP) を使用する場合に最も便利です。ネイティブ GCP 統合を使用する場合、支払うのは 1 つのロードバランサに対してのみで、Ingress は「スマート」であるため、すぐに使用できるさまざまな機能 (SSL、認証、ルーティングなど) も利用できます。