Nginx Ingress Controller は、パブリックネットワークアクセスとプライベートネットワークアクセス、パブリックネットワークアクセスのみ、プライベートネットワークアクセスのみの 3 つのモードを同時にサポートするように構成でき、さまざまなネットワーク環境におけるクライアントのアクセス要件を満たします。
クラスターでは、ロードバランサーインスタンスがクライアントのリクエストを受信し、Nginx Ingress Controller ワークロードに転送します。その後、Nginx Ingress Controller ワークロードはリクエストを他のサービスに転送します。
Nginx Ingress のパブリックネットワークとプライベートネットワーク両方への対応構成
パブリックネットワークアクセスとプライベートネットワークアクセスの両方を同時にサポートするには、Nginx Ingress Controller のバックエンド Pod 用に 2 つのサービスをデプロイし、それぞれをパブリックネットワークタイプとプライベートネットワークタイプのロードバランサーインスタンスに関連付けます。
-
現在のロードバランサーのネットワークタイプを確認します。
kubectl describe service -n kube-system nginx-ingress-lb | grep "service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type" -
nginx-ingress-lb-new.yamlという名前のファイルを作成して保存し、kubectl apply -f nginx-ingress-lb-new.yamlを実行してサービスを作成します。プライベートネットワークサービスの例
apiVersion: v1 kind: Service metadata: name: nginx-ingress-lb-intranet namespace: kube-system labels: app: nginx-ingress-lb annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet spec: type: LoadBalancer externalTrafficPolicy: "Cluster" ports: - port: 80 name: http targetPort: 80 - port: 443 name: https targetPort: 443 selector: app: ingress-nginx -
新しく作成されたサービスのステータスを確認します。
200が返された場合、新しいサービスは正常に機能しています。curl -s -o /dev/null -w "%{http_code}\n" http://$(kubectl get service -n kube-system nginx-ingress-lb-intranet -o jsonpath='{.status.loadBalancer.ingress[0].ip}') -
kubectl get service nginx-ingress-lb-intranetを実行し、サービスの外部 IP を記録してから、新しいサービスタイプに従って DNS を構成します。-
DNS コンソールにログインします。
-
DNS レコードを追加します。
フィールド
[値]
レコードタイプ
A
ホストレコード
ご希望のサブドメイン (例: intranet) を入力します。
レコード値
新しいサービスの IP アドレス。
-
ネットワークタイプの変更
この操作では、ロードバランサーインスタンスを置き換えるためにサービスを削除して再作成する必要があり、Nginx Ingress の一時的な中断が発生します。削除されたロードバランサーインスタンスとその対応する IP は回復できません。
-
既存のサービスを削除します。
kubectl delete service nginx-ingress-lb -n kube-system -
目的のネットワークタイプで新しいサービスを作成します。
プライベートネットワークサービス
apiVersion: v1 kind: Service metadata: name: nginx-ingress-lb namespace: kube-system labels: app: nginx-ingress-lb annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet spec: type: LoadBalancer externalTrafficPolicy: "Cluster" ports: - port: 80 name: http targetPort: 80 - port: 443 name: https targetPort: 443 selector: app: ingress-nginxパブリックネットワークサービス
apiVersion: v1 kind: Service metadata: name: nginx-ingress-lb namespace: kube-system labels: app: nginx-ingress-lb spec: type: LoadBalancer externalTrafficPolicy: "Cluster" ports: - port: 80 name: http targetPort: 80 - port: 443 name: https targetPort: 443 selector: app: ingress-nginx -
新しいサービスのステータスを確認します。
200が返された場合、新しいサービスは正常に機能しています。curl -s -o /dev/null -w "%{http_code}\n" http://$(kubectl get service -n kube-system nginx-ingress-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}') -
kubectl get service nginx-ingress-lbを実行し、サービスの外部 IP を記録してから、新しいサービスタイプに従って DNS を構成します。
トラブルシューティング
なぜ新しいサービスを先に作成してから古いサービスを削除できないのですか?
Nginx Ingress Controller のネットワークタイプを変更する場合、新しいサービスを先に作成してから古いサービスを削除するというアプローチは使用できません。古いサービスを先に削除してから新しいサービスを作成する必要があります。これは、Nginx Ingress Controller コンポーネントがアップグレードされる際に、ワークロードがサービスのデフォルト名 (nginx-ingress-lb) と一致する必要があるためです。サービスは重複する名前を持つことができないため、新しいサービスを先に作成してから古いサービスを削除すると、ワークロードがロードバランサーインスタンスと一致できなくなり、アップグレードの失敗につながります。
クライアントがアクセスする IP がコンソールに表示されるエンドポイントと一致しないのはなぜですか?
コンソールの Ingress ページに表示される [エンドポイント] は、nginx-ingress-lb という名前のサービスに属するロードバランサーインスタンスの IP アドレスを指します。複数の LoadBalancer タイプのサービスが構成されている場合でも、Nginx Ingress はすべてのリクエストを正常に転送できますが、コンソールには他のサービスのロードバランサー IP は表示されません。クライアントが実際にアクセスする IP は、使用されているロードバランサーインスタンスによって異なります (これはドメイン名解決テストで確認できます) 。そのため、コンソールに表示される [エンドポイント] と一致しない場合があります。
nginx-ingress-lb を削除し、同じ名前でサービスを再作成した場合、Ingress によって表示されるエンドポイントは、Ingress リソースを更新することでリフレッシュする必要があります。
構成失敗時の回復手順
構成が失敗した場合は、できるだけ早く以下の手順を順番に実行してください。
-
重複する名前によるコンポーネント作成の失敗を避けるため、新しく作成されたサービスを削除します。
-
コンソールから Nginx Ingress Controller コンポーネントをアンインストールして再インストールし、クラスターに新しいデフォルトサービスを作成し、Nginx Ingress エントリポイントを復元します。
-
DNS を構成して、新しいデフォルトサービス (
nginx-ingress-lb) のドメイン名解決を追加し、転送が正常に機能するかどうかをテストします。