1. Kubernetes Service Exposureの紹介
kubernetesの1.2バージョン以降、kubernetesは外部公開サービスを実現するためのIngressオブジェクトを提供しています。これまでのところ、kubernetesにはサービスを公開するための合計3つの方法があります。
- LoadBlancerサービス
- NodePortサービス
- イングレス
1.1、LoadBlancerサービス
LoadBlancerサービスは、クラウドプラットフォームと深く統合されたkubernetesのコンポーネントです。LoadBlancerサービスを使用してサービスを公開する場合、実際に基盤となるクラウドプラットフォームに適用してロードバランサーを作成することによりサービスを公開します。LoadBlancerサービスでサポートされるクラウドプラットフォームは比較的完璧です、外部GCE、DigitalOcean、国内のAlibaba Cloud、プライベートクラウドOpenstackなど。LoadBlancerサービスはクラウドプラットフォームと深く統合されているため、一部のクラウドプラットフォームでのみ使用できます。
1.2、NodePortサービス
NodePort Serviceは、その名前が示すように、基本的にはクラスターの各ノードのポートを公開し、このポートを特定のサービスにマッピングすることで実現されます。各ノードには多数のポート（0〜65535）がありますが、セキュリティと使いやすさ（サービスが多すぎ、ポートの競合がある場合、メッセージは混乱します）実際の使用はそれほど多くない場合があります
1.3、イングレス
Ingressこのことは1.2以降に登場しました。Ingressを使用すると、nginxやその他のオープンソースのリバースプロキシロードバランサーを使用して外部公開サービスを実現できます。
Ingressを使用する場合、通常3つのコンポーネントがあります。
- リバースプロキシロードバランサー（nginx）
- Ingress Controller（Monitor、nginx、Ingress Controllerが1つのコンポーネントに統合されているため、nginxを個別にデプロイする必要はありません）
- Ingress（ルール定義）
1.3.1、リバースプロキシロードバランサー
リバースプロキシロードバランサーは非常にシンプルです。つまり、nginx、apacheなどです。リバースプロキシロードバランサーはクラスターに自由にデプロイでき、レプリケーションコントローラー、デプロイメント、DaemonSetなどを使用できますが、個人的にはDaemonSetをデプロイするのが好きです。より便利
1.3.2、イングレスコントローラー
Ingress Controllerは本質的にモニターと理解できます。IngressControllerは常にkubernetes APIと対話して、ポッドの追加と削減、サービスの増減などのバックエンドサービスとポッドのリアルタイムの変更を検知します。これらの変更が取得されるとその後、Ingressコントローラーは次のIngressを組み合わせて構成を生成し、リバースプロキシロードバランサーを更新し、その構成を更新してサービス検出の役割を実現します
1.3.3、イングレス
Ingressはルール定義の単純な定義です。これは、インバウンド接続がクラスターサービスに到達することを承認する一連のルールです。たとえば、特定のドメイン名はサービスに対応します。つまり、特定のドメイン名のリクエストが着信すると、サービスに転送されます。このルールはIngressに関連付けられますコントローラーが結合され、次にIngress Controllerがそれをロードバランサー構成に動的に書き込み、全体的なサービス検出とロードバランシングを実現します
上記の図から明らかなように、実際にはnginxなどのロードバランサーによってリクエストが引き続きインターセプトされ、IngressコントローラーはIngressとやり取りすることで特定のドメイン名に対応するサービスを学習し、kubernetes APIとやり取りすることでサービスを学習しますアドレスおよびその他の情報。合成後、構成ファイルが生成されてロードバランサーにリアルタイムで書き込まれ、ロードバランサーがルールを再ロードしてサービス検出、つまり動的マッピングを実装します。
上記を理解した後、これはロードバランサーをデーモンセットとしてデプロイする理由の良い例です。リクエストは最初にロードバランサーによってインターセプトされるため、各ノードにデプロイされます。ホストポートはポート80を監視します。次に、ロードバランサーが他の方法でどこにデプロイされているかがわからないという問題を解決します。同時に、各ノードで80にアクセスすると、要求を正しく解決できます。フロントエンドに別のnginxを配置すると、負荷分散のレイヤーが実現します。
次のブログ投稿を参照してください。
https://mritd.me/2016/12/06/try-traefik-on-kubernetes/
https://mritd.me/2017/03/04/how-to-use-nginx-ingress/
https://blog.csdn.net/zll_0405/article/details/88723082
https://www.kubernetes.org.cn/1885.html