CKA 認定の合格率を向上: Kubernetes Ingress 7 層プロキシの完全ガイド!

1. Ingress の紹介

Ingress は、外部リクエストをクラスター内のサービスに送信する Kubernetes のメカニズムです。サービスをクラスター外部の URL にマッピングすることで、サービスの外部アクセスが可能になります。 Ingress は、トラフィック負荷分散やドメイン名ベースの仮想ホスティングなどの機能を提供しながら、外部 URL 経由でアクセスできるようにクラスター内のサービスを構成することをサポートします。

簡単に言えば、Ingress は、Nginx 構成を手動で変更し、ドメイン名とサービスのマッピングを Ingress オブジェクトに構成するという面倒な手順を抽象化します。 YAML ファイルを使用して Ingress オブジェクトを作成および更新することで、Nginx 構成ファイルを手動で操作する必要がなくなり、ドメイン名とサービスの関係をより便利な方法で管理できるようになります。

しかし、これによって「Nginx はこれらの変更をどのように処理すればよいのか」という疑問が生じます。ここで Ingress Controller が登場し、具体的には Nginx がこれをどのように処理するかという問題を解決します。 Ingress Controller は Kubernetes API と対話して、クラスター内の Ingress ルールの変更をリアルタイムで検出します。変更があると、Ingress コントローラーはこれらのルールを読み取り、独自のテンプレートに基づいて対応する Nginx 構成を生成します。次に、この構成を Nginx Pod に書き込み、最後に Nginx のリロードをトリガーして、構成が有効になるようにします。

Ingress と Ingress Controller の連携により、外部アクセスの管理がより柔軟かつ便利になり、Nginx 構成を手動で変更する手間がなくなり、サービスとドメイン名のマッピング関係に集中できるようになり、Kubernetes クラスターの保守性が向上しました。

1. Ingress Controller の概要

Ingress Controller は、7 層の負荷分散スケジューラです。これはクライアント要求の最初のストップとして機能し、すべての外部要求を受信して処理します。この 7 層の負荷分散スケジューラの動作により、リクエストはリバースプロキシを通過し、最終的にバックエンド Pod にルーティングされます。一般的な 7 層ロードバランサーには、nginx、traefik などがあります。よく知られている nginx を例にとると、リクエストが nginx に到達すると、nginx はアップストリームを通じてバックエンドの Pod アプリケーションへのリバースプロキシを構成します。

イングレスコントローラ

ただし、バックエンド Pod の IP アドレスは動的に変更されます。この問題を解決するために、サービスを導入しました。このサービスは実際のサービスではありませんが、バックエンドのポッドをグループ化するために使用されます。したがって、アップストリームを構成するときは、バックエンド Pod の特定の IP アドレスを気にせずに、サービスのアドレスを入力するだけで済みます。

この設計により、Ingress コントローラーはバックエンドポッドの変更を柔軟に処理し、リクエストがクラスター内のサービスに正しくルーティングされることを保証できます。このパターンにより、ポッドの IP アドレスが絶えず変更されることで発生する問題を心配することなく、バックエンドサービスの変更をより簡単に管理できるようになります。

2. イングレスリソース

最小限の Ingress リソースの例:

 apiVersion:networking.k8s.io/v1 kind:Ingress metadata: name:minimal-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target:/ spec: ingressClassName:nginx-example rules: -http: paths: -path:/testpath pathType:Prefix backend: service: name:test port: number:80

Ingress では、apiVersion、kind、metadata、spec フィールドを指定する必要があります。 Ingressオブジェクトの名前は有効なDNSサブドメイン名である必要があります[1]。

3. Ingress Controller プロキシ k8s 内部アプリケーションプロセス

Ingress コントローラーをデプロイします。私たちのイングレスコントローラはnginxを使用しています
Pod アプリケーションを作成します。コントローラーを通じてポッドを作成できます
ポッドをグループ化するサービスを作成する
Ingress httpを作成し、http経由でアプリケーションへのアクセスをテストします。
Ingress httpsを作成し、https経由でアプリケーションへのアクセスをテストします。

Ingress の要件を満たすには、Ingress コントローラが必要です。 Ingress リソースを作成しただけでは効果はありません。

イングレス

（1）ingress-nginxをデプロイする

ここでのテストには killercoda プラットフォームも使用されます。プラットフォームは、K8S 環境の最新バージョン V1.29.0 を展開します。

この環境では Ingress はデプロイされていません。以下では、ingress-nginx[2]のデプロイメントを例に挙げます。公式の ingress-nginx を調べると、V1.29.0 は Ingress-NGINX の V1.10.0 または v1.9.6 に対応していることがわかります。次のように：

Ingress-NGINX バージョンリスト

次のコマンドを実行して、Ingress-NGINX V1.10.0 をデプロイします。

 kubectl apply -f \ https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider/cloud/deploy.yaml

上記のコマンドを実行すると、次の結果が出力されます。

デプロイメントのステータスを表示するには、次のコマンドを使用します。

 controlplane $ kubectl get pod -n ingress-nginx NAME READY STATUS RESTARTS AGE ingress-nginx-admission-create-d69wp 0/1 Completed 0 102s ingress-nginx-admission-patch-hkv66 0/1 Completed 0 102s ingress-nginx-controller-7dcdbcff84-gfqcs 1/1 Running 0 102s controlplane $ kubectl get svc -n ingress-nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress-nginx-controller LoadBalancer 10.98.23.38 <pending> 80:30770/TCP,443:31444/TCP 3m57s ingress-nginx-controller-admission ClusterIP 10.102.219.183 <none> 443/TCP 3m57s

（２）バックエンドTomcatサービスのデプロイ

Tomcat サービスをデプロイして Ingress HTTP プロキシ k8s 内部サイトをテストし、次のリソースリストを記述します。

 apiVersion:v1 kind:Service metadata: name:tomcat namespace:default spec: selector: app:tomcat release:canary ports: -name:scport targetPort:8080 port:8009 --- apiVersion:apps/v1 kind:Deployment metadata: name:tomcat-deploy namespace:default spec: replicas:2 selector: matchLabels: app:tomcat release:canary template: metadata: labels: app:tomcat release:canary spec: containers: -name:tomcat image:tomcat:8.5.34-jre8-alpine imagePullPolicy:IfNotPresent ports: -name:containerport containerPort:8080 name:ajp containerPort:8009

ポッドが正常にデプロイされているかどうかを確認します。

 controlplane $ kubectl apply -f ingress-demo.yaml service/tomcat created deployment.apps/tomcat-deploy created controlplane $ kubectl get pod NAME READY STATUS RESTARTS AGE tomcat-deploy-7c67c4d459-5s859 1/1 Running 0 11m tomcat-deploy-7c67c4d459-bvp2k 1/1 Running 0 11m

（3）イングレスルールを書く

apiVersion:networking.k8s.io/v1 kind:Ingress metadata: name:ingress-myapp namespace:default annotations: nginx.ingress.kubernetes.io/rewrite-target:/ spec: ingressClassName:nginx rules:# 定义后端的转发规则-host:tomcat.test.com# 通过域名进行转发http: paths: -path:/#配置访问路径，如果通过url进行转发。需要修改，空的默认访问路径是"/" pathType:Prefix backend:# 配置后端服务service: name:tomcat# 配置关联的serverce port: number:8080# service暴露的端口

ingressClassName: この値は、kubectl get ingressclasses を通じて取得できます。

ingress-myapp の詳細情報を表示します。

 controlplane $ kubectl apply -f ingress-myapp.yaml ingress.networking.k8s.io/ingress-myapp created controlplane $ kubectl get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ingress-myapp nginx tomcat.test.com 80 8s controlplane $ kubectl describe ingress ingress-myapp Name: ingress-myapp Labels: <none> Namespace: default Address: Ingress Class: nginx Default backend: <default> Rules: Host Path Backends ---- ---- -------- tomcat.test.com / tomcat:8080 () Annotations: nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 62s nginx-ingress-controller Scheduled for sync

次に示すように、ingress-nginx がどのノードにデプロイされているかを確認します。

上図から、ingress-nginx が node1 にデプロイされ、SVC メソッドが LoadBalancer を通じてデプロイされていることがわかります。このバックエンド Tomcat サービスにアクセスする場合は、ドメイン名を解決する必要があります。次のように：

 ...省略.. 172.30.2.2 tomcat.test.com

通常のアクセスは次のとおりです。

4. CKAの実際の質問

（１）実際のテスト問題のスクリーンショット

（２）中国の分析

k8s クラスター環境を切り替えます: kubectl config use-context k8s

タスク：

次のように新しい nginx lngress リソースを作成します。

名前: pong 名前空間: ing-internal

サービスポート 5678 を使用してパス /hi のサービス hi を公開します。

次のコマンドを使用して、hi サービスが利用可能かどうかを確認できます。curl -kL/hi は hi を返します。

（３）公式参考資料

イングレス[3]

（４）質問を解いて答える

k8s クラスター環境を切り替えます。

 kubectl config use-context k8s

pong.yaml というファイルを作成します。リソースの内容は次のとおりです。

 apiVersion:networking.k8s.io/v1 kind:Ingress metadata: name:pong namespace:ing-internal annotations: nginx.ingress.kubernetes.io/rewrite-target:/ spec: ingressClassName:nginx-example rules: -http: paths: -path:/hi pathType:Prefix backend: service: name:hi port: number:5678

ingressClassName の値は、試験中に kubectl get ingressclasses を通じて取得することをお勧めします。
質問では service.name の値が示されていません。試験中に kubectl get svc で確認することをお勧めします。

リソースリストを送信:

 kubectl apply -f pong.yaml

curl -kL<INTERNAL_IP>/hi を実行して、hi が返されるかどうかを確認します。

参考文献:

[1] DNSサブドメイン名: https://kubernetes.io/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names
[2]イングレス-nginx: https://github.com/kubernetes/ingress-nginx
[3]イングレス: https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/

<<: 知らないかもしれないKubernetesのヒント13選

>>: 一般的な Kubernetes 終了コードの解釈