最近、NodePorts、LoadBalancers、およびIngressの違いを尋ねられました。 これらはすべて、外部トラフィックをクラスターに取り込むさまざまな方法です。 それらがどのように異なるのか、それぞれをいつ使用するのかを見てみましょう。
注： 推奨事項は、 Google Kubernetes Engineに基づいています 。 別のクラウド、自分のサーバー、ミニキューブなどで作業している場合、違いがあります。 技術的な詳細には触れません。 詳細については、 公式ドキュメントを参照してください。
Clusterip
ClusterIPはデフォルトのKubernetesサービスです。 クラスター内の他のアプリケーションがアクセスできるクラスター内のサービスを提供します。 外部アクセスなし。
ClusterIPサービスのYAMLは次のとおりです。
apiVersion: v1 kind: Service metadata: name: my-internal-service selector: app: my-app spec: type: ClusterIP ports: - name: http port: 80 targetPort: 80 protocol: TCP
インターネットからアクセスできない場合、ClusterIPサービスについて説明したのはなぜですか？ 方法があります：Kubernetesプロキシを使用する！
Kubernetesプロキシサーバーを起動します。
$ kubectl proxy --port=8080
次のスキームを使用して、Kubernetes APIをナビゲートしてこのサービスにアクセスできます。
http：// localhost：8080 / api / v1 / proxy / namespaces / / services / <SERVICE-NAME>：<PORT-NAME> /
このアドレスを使用して、上記のサービスにアクセスします。
いつ使用しますか？
Kubernetesプロキシを使用してサービスにアクセスするには、いくつかのシナリオがあります。
他の目的のためにラップトップからサービスをデバッグしたり、サービスに直接接続したりする
内部トラフィックの解決、内部パネルの表示など。
この方法では認証されたユーザーとしてkubectlを実行する必要があるため、インターネット上のサービスへのアクセスや本番サービスへのアクセスを提供するために使用するべきではありません。
NodePort
NodePortサービスは、外部トラフィックをサービスに誘導する最も基本的な方法です。 NodePortは、その名前が示すとおり、すべてのノード（仮想マシン）に対して指定されたポートを開き、このポートへのトラフィックはサービスにリダイレクトされます。
NodePortサービスのYAMLは次のようになります。
apiVersion: v1 kind: Service metadata: name: my-nodeport-service selector: app: my-app spec: type: NodePort ports: - name: http port: 80 targetPort: 80 nodePort: 30036 protocol: TCP
本質的に、NodePortサービスには通常のClusterIPサービスとは2つの違いがあります。 最初はNodePortタイプです。 nodePortと呼ばれる追加のポートがあり、ノードで開くポートを示します。 このポートを指定しない場合、ランダムが選択されます。 ほとんどの場合、Kubernetesにポート自体を選択させます。 thockinが言うように、ポートの選択はそれほど単純ではありません。
いつ使用しますか？
この方法には多くの欠点があります。
港には1つのサービスしかありません
ポート30000〜32767のみが使用可能です。
ホスト/仮想マシンのIPアドレスが変更された場合、それを把握する必要があります
これらの理由から、本番環境でこの方法を使用してサービスへのアクセスを直接提供することはお勧めしません。 しかし、サービスの継続的な可用性があなたにとって無関心であり、コストのレベルがそうでない場合、この方法はあなたのためです。 このようなアプリケーションの良い例は、デモまたは一時的なギャグです。
ロードバランサー
LoadBalancerサービスは、インターネットでサービスを提供する標準的な方法です。 GKEで、彼はIPアドレスを提供するNetwork Load Balancerをデプロイします。 このIPアドレスは、すべてのトラフィックをサービスに転送します。
いつ使用しますか？
サービスを直接開く場合、これがデフォルトの方法です。 指定されたポートのすべてのトラフィックは、サービスに向けられます。 フィルタリングなし、ルーティングなしなど これは、HTTP、TCP、UDP、Websocket、gRPCなどのようなタイプのトラフィックをサービスに向けることができることを意味します。
！ ただし、欠点が1つあります。 LoadBalancerを使用して展開する各サービスには独自のIPアドレスが必要です。これにはかなりの費用がかかります。
イングレス
上記の例とは異なり、Ingress自体はサービスではありません。 複数のサービスに直面し、「インテリジェントルーター」またはクラスターエントリポイントとして機能します。
豊富な機能を備えたさまざまなタイプのIngressコントローラーがあります。
GKEコントローラーは、デフォルトでHTTP（S）ロードバランサーを起動します。 同時に、パスとサブドメインに基づくバックエンドサービスへのルーティングが利用可能になります。 たとえば、foo.yourdomain.comにすべてをfooサービスに送信し、パスyourdomain.com/bar/にbarサービスへのすべての添付ファイルを送信します。
L7 HTTPロードバランサーを使用したGKE上のIngressオブジェクトのYAML は次のとおりです。
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: my-ingress spec: backend: serviceName: other servicePort: 8080 rules: - host: foo.mydomain.com http: paths: - backend: serviceName: foo servicePort: 8080 - host: mydomain.com http: paths: - path: /bar/* backend: serviceName: bar servicePort: 8080
いつ使用しますか？
一方では、イングレスはサービスを公開する最良の方法の1つです。 一方、最も難しいものの一つ。 多くのIngressコントローラーがあります： Google Cloud Load Balancer 、 Nginx 、 Contour 、 Istioなど。 cert-managerなど、サービス用のSSL証明書を自動的に提供するIngressコントローラー用のプラグインがあります。
Ingressは、すべてのサービスが共通のL7プロトコル（通常はHTTP）を使用する場合、複数のサービスを同じIPアドレスに公開するのに適しています。 組み込みのGCP統合を使用すると、1つのロードバランサーに対してのみ料金を支払います。 また、Ingressはスマートなので、多くの機能をすぐに使用できます（たとえば、SSL、認証、ルーティングなど）。
図をありがとう、 アフメットアルプバルカン 。
これは技術的に最も正確な図ではありませんが、NodePortの動作をよく示しています。
オリジナル： Kubernetes NodePort vs LoadBalancer vs Ingress？ 何を使うべきですか？ 。