Ingress vs Load Balancer
回答:
ロードバランサー： kubernetes LoadBalancerサービスは、kubernetesクラスターにはないが他の場所に存在する外部ロードバランサーを指すサービスです。ポッドが外部からルーティング可能であると想定して、ポッドを操作できます。GoogleとAWSはこの機能をネイティブで提供しています。Amazonの観点から見ると、これはAWSで実行されている場合、ELBおよびkubernetesに直接マッピングされ、デプロイされた各LoadBalancerサービスのELBインスタンスを自動的にプロビジョニングおよび構成できます。
Ingress：Ingressは実際には、それらをリッスンしているコントローラーに渡す一連のルールです。一連の上りルールをデプロイできますが、それらを処理できるコントローラーがない限り、何も起こりません。LoadBalancerサービスは、構成する場合、上りルールをリッスンできます。
クラスタの外部に外部からルーティング可能なIPを持つが、クラスタ内に存在するポッドを指すNodePortサービスを作成することもできます。これはIngress Controllerである可能性があります。
イングレスコントローラーは、イングレスルールを解釈するように構成されたポッドです。kubernetesでサポートされている最も一般的なIngressコントローラーの1つはnginxです。Amazonに関しては、ALB は入力コントローラーとして使用できます。
たとえば、この nginxコントローラーは、定義した上りルールを取り込み、それらをnginx.confファイルに変換して、ポッドでロードして開始することができます。
たとえば、次のように入力を定義したとします。
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
次にnginxコントローラポッドを検査すると、で定義された次のルールが表示され/etc/nginx.confます。
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginxは、クラスター内のhttp://kubernetes.foo.bar/appサービスを指すようにルーティングするルールを作成しましたappsvc。
NodePort、LoadBalancer、Ingressの違いを説明する非常に興味深い記事を見つけました。
記事の内容から：
LoadBalancer：
LoadBalancerサービスは、サービスをインターネットに公開する標準的な方法です。GKEでは、これによりNetwork Load Balancerが起動し、すべてのトラフィックをサービスに転送する単一のIPアドレスが提供されます。
サービスを直接公開する場合は、これがデフォルトの方法です。指定したポート上のすべてのトラフィックがサービスに転送されます。フィルタリングやルーティングなどはありません。つまり、HTTP、TCP、UDP、WebSocket、gRPCなど、ほぼすべての種類のトラフィックを送信できます。
大きな欠点は、LoadBalancerで公開する各サービスが独自のIPアドレスを取得することと、公開されたサービスごとにLoadBalancerの料金を支払う必要があることです。
イングレス：
Ingressは実際には一種のサービスではありません。代わりに、複数のサービスの前に置かれ、クラスターへの「スマートルーター」またはエントリポイントとして機能します。
Ingressを使用すると、さまざまなことを実行できます。また、機能が異なるIngressコントローラーにはさまざまな種類があります。
デフォルトのGKE入力コントローラは、HTTP（S）ロードバランサを起動します。これにより、パスベースとサブドメインベースの両方のルーティングをバックエンドサービスに行うことができます。たとえば、foo.yourdomain.com上のすべてをfooサービスに送信し、yourdomain.com / bar /パスの下にあるすべてをbarサービスに送信できます。
Ingressはおそらくサービスを公開するための最も強力な方法ですが、最も複雑な場合もあります。Google Cloud Load Balancer、Nginx、Contour、Istioなど、さまざまなタイプのIngressコントローラーがあります。cert-managerのような、サービスのSSL証明書を自動的にプロビジョニングできるIngressコントローラー用のプラグインもあります。
Ingressは、同じIPアドレスで複数のサービスを公開する場合に最も便利です。これらのサービスはすべて同じL7プロトコル（通常はHTTP）を使用します。ネイティブのGCP統合を使用している場合、1つのロードバランサーに対してのみ支払います。Ingressは「スマート」であるため、多くの機能（SSL、Auth、ルーティングなど）をすぐに利用できます。
TL：DR
- Ingressは、パブリックネットワーク（インターネット）と、Apiの実装を公開するKubernetesサービスの間にあります。
- Ingressは、負荷分散、SSL終了、名前ベースの仮想ホスティングを提供できます。
- Ingress機能により、単一のドメイン名から複数のAPIまたはアプリケーションを安全に公開できます。
実用的なユースケースから始めましょう。単一のドメイン名でデプロイするために、サービス実装パッケージ（明快さと簡潔さのためにASIP）に裏打ちされた複数のApisがあります。あなたは最先端の開発者なので、ASIPごとに個別のデプロイメントが必要なマイクロサービスアーキテクチャを実装し、個別にアップグレードまたはスケーリングできるようにしました。もちろん、これらのASIPは個別のDockerコンテナーにカプセル化されており、コンテナーリポジトリからKubernetes（K8）で使用できます。
これをGoogleのGKE K8にデプロイするとします。持続的な可用性を実装するために、各ASIPインスタンス（レプリカ）は、各VMが独自のクラウド内部IPアドレスを持つ異なるノード（VM）にデプロイされます。各ASIPデプロイメントは、「deployment.yaml」という適切な名前のファイルで構成されます。このファイルでは、特に、特定のASIP K8のレプリカのデプロイ数を宣言的に指定します。
次のステップでは、APIを外部の世界に公開し、デプロイされたASIPインスタンスの1つにリクエストを送ります。同じASIPの多くのレプリカが異なるノードで実行されているため、これらのレプリカ間で要求を分散するものが必要です。これを解決するには、外部に公開され、IPアドレスを介してアクセスできるK8sサービス（KServ）を構成する「service.yaml」ファイルを作成して適用します。このKServは、構成されたASIP間でのAPIのリクエスト分散を担当します。ASIPのノードに障害が発生して再起動すると、KServはK8sマスターによって自動的に再構成されます。このような場合、内部IPアドレスは再利用されないため、KServに新しいASIPの配置場所を通知する必要があります。
ただし、同じドメイン名で公開される他のApiサービスパッケージがあります。新しいKServをスピンすると、新しい外部IPアドレスが作成され、同じドメイン名で公開することはできません。これがIngressの出番です。
Ingressは、インターネットと外部に公開するすべてのKServiceの間にあります。Ingressは、負荷分散、SSL終了、名前ベースの仮想ホスティングを提供できます。後者の容量では、URLを分析することにより、着信要求を適切なサービスにルーティングできます。もちろん、Ingressを構成して適用するには、「ingress.yaml」ファイルを使用して、正しいKServにリクエストを送信するために必要な書き換えとルートを指定する必要があります。
インターネット-> Ingress-> K8sサービス->レプリカ
したがって、適切なIngress、KServices、ASIP構成を使用すると、同じドメイン名を使用して多くのAPIを安全に公開できます。
クラスタ内のポッドが外部トラフィックを受信できるようにする方法は4つあります
。1。）HostNetworkingを使用したポッド：trueおよび（ノードごとに1つのポッドがホストノードのポートを直接リッスンすることを許可します。Minikube、ベアメタル、およびrasberry piが時々行くホストノードがポート80/443でリッスンできるようにするこのルートは、ロードバランサーまたは高度なクラウドロードバランサー構成を使用できないようにします。また、SNATを回避したり、externalTrafficPolicyの同様の効果を達成したりするのに役立つKubernetesサービスをバイパスします：シナリオのローカルAWSのようにサポートされていない場合）
。）NodePort Service
3.）LoadBalancer Service（NodePort Serviceに基づいて構築）
4.）Ingress Controller + Ingress Objects（上記に基づいて構築）
クラスターでホストされている10のWebサイトがあり、それらすべてを外部トラフィックに公開したいとします。
*タイプLoadBalancer Serviceを使用する場合、10個のHAクラウドロードバランサーを生成します（それぞれコストがかかります）
*タイプIngress Controllerを使用する場合、1個のHAクラウドロードバランサーを生成し（お金を節約）、それがIngressを指しますクラスターで実行されているコントローラー。
Ingress Controllerは次のとおりです。
- クラスターで実行されているポッドのデプロイメントによってサポートされるタイプLoad Balancerのサービス。
- 各ポッドは2つのことを行います。
- クラスター内で実行されるレイヤー7ロードバランサーとして機能します。（Nginxが人気の多くのフレーバーで来ます）
- クラスター内のIngressオブジェクトに基づいて動的に構成されます
（Ingressオブジェクトは、レイヤー7ロードバランサーの宣言的な構成スニペットと考えることができます）。
クラスター内のL7 LB / Ingressコントローラーは、クラスター内のクラスターIPサービスへのトラフィックを負荷分散/リバースプロキシします。タイプTLS証明書のKubernetesシークレットとそれを参照するIngressオブジェクトがある場合、HTTPSを終了することもできます。）
Ingress：Ingress Object + Ingress Controller
Ingressオブジェクト：
サービスオブジェクトと同じですが、それ自体では何もしません。Ingressオブジェクトは、サービスオブジェクトが実際にサービスを作成する一方で、リクエストパス、リクエストドメイン、ターゲットkubernetesサービスなどを指定することにより、レイヤー7トラフィックをクラスターにルーティングする方法を説明します
入力コントローラー：
以下のサービス：
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Objects
3. Creates internal L7 routing rules based on these Ingress Objects
たとえば、Nginx Ingress Controllerは、サービスを使用してポート80および443でリッスンし、新しいIngressオブジェクトを読み取って、それを動的にnginx.confに配置する新しいサーバー{}セクションに解析します。
LoadBalancer：外部ロードバランサープロバイダー+サービスタイプ
外部ロードバランサープロバイダー：
外部ロードバランサープロバイダーは通常、AWSやGKEなどのクラウドで構成され、外部ロードバランサーの作成を通じて外部IPを割り当てる方法を提供します。この機能は、サービスをタイプ「LoadBalancer」として指定することで使用できます。
サービスの種類：
サービスタイプがLoadBalancerに設定されている場合、Kubernetesは、Kubernetesポッドのエントリを使用して外部ロードバランサーを作成し、プログラムして、外部IPを割り当てようとします。
Kubernetesサービスコントローラーは、外部ロードバランサー、ヘルスチェック（必要な場合）、ファイアウォールルール（必要な場合）の作成を自動化し、クラウドプロバイダーによって割り当てられ、新しく作成または構成されたLoadBalancerの外部IPを取得して、サービスオブジェクト。
関係：
イングレスコントローラーサービスは多くの場合LoadBalancerタイプとしてプロビジョニングされるため、httpおよびhttpsリクエストを外部IP経由で特定の内部サービスにプロキシ/ルーティングできます。
ただし、LoadBalancerは厳密には必要ありません。なぜなら、hostNetworkまたはhostPortを使用することにより、技術的にはホスト上のポートをサービスにバインドできる（ホストの外部ip：portを介してアクセスできるようにする）からです。正式にはこれはお勧めできませんが、実際のノードのポートを使い果たすためです。
参照：
https://kubernetes.io/docs/concepts/configuration/overview/#services
https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/
https://kubernetes.io/docs/concepts/services-networking/ingress/