Alibaba Cloud ACK で複数の NGINX Ingress コントローラーをデプロイしてトラフィックを隔離する - Container Service for Kubernetes

Alibaba Cloud Container Service for Kubernetes (ACK) クラスターでは、アドオン管理 のデフォルトコントローラーに加えて、Helm アプリケーションを使用して複数の独立した NGINX Ingress コントローラーをインストールできます。これにより、異なるサービスや環境専用のトラフィックエントリポイントを作成したり、個別のインターネット向けおよび内部向け SLB インスタンスでトラフィックを隔離したり、特定のアプリケーションに異なるコントローラー構成やバージョンを提供したりすることが可能になります。単一のコントローラーでインターネット向けと内部向けの両方のトラフィックを管理する場合とは異なり、このアプローチでは完全な障害および構成の隔離が実現できます。

重要

Helm アプリケーションを使用してインストールしたコントローラーは、アドオン管理 のデフォルトコントローラーと以下の重要な点で異なります。

統合機能：アドオン管理 のコントローラーは、カナリアリリース、ログとモニタリング、クラスター検査など、より多くの統合機能を提供します。
責任範囲：Helm を使用してインストールされたコントローラーのライフサイクル (バージョンアップグレード、構成変更、トラブルシューティングなど) は、お客様の責任で管理する必要があります。

仕組み

各コントローラーは、一意の IngressClass 名によって識別されます。Ingress リソースを作成する際に、spec.ingressClassName フィールドを使用して、どのコントローラーがそれを処理すべきかを宣言できます。IngressClass 名に一致するコントローラーのみが、対応する Ingress ルールをリッスンして適用するため、トラフィックの隔離が実現されます。

以下の図は、インターネット向けと内部向けのトラフィックを隔離する例を示しています。

前提条件

クラスターのバージョンが 1.22 以降であること。

バージョン 1.20 以前を実行しているクラスターのコンポーネントバージョンは、メンテナンスが終了しています。詳細については、「[製品発表] NGINX Ingress controller v1.2 以前のメンテナンス終了」をご参照ください。クラスターをアップグレードするには、「ACK クラスターの手動アップグレード」をご参照ください。

Helm を使用した新しい Ingress コントローラーのデプロイ

「ACK クラスター」ページで、クラスターの名前をクリックします。左側のナビゲーションウィンドウで、Applications > Helm をクリックします。

デプロイ をクリックし、画面の指示に従って ack-ingress-nginx-v1 をインストールします。

以下の主要なパラメーターを設定します。他のパラメーターはデフォルト値のままでかまいません。

パラメーター	説明
アプリケーション名	名前はクラスター内で一意である必要があります。重要この名前は、Service リソースを生成するためのプレフィックスとして使用されます。Service 名は `<アプリケーション名>-ack-ingress-nginx-v1-controller` というフォーマットになります。内部向け LoadBalancer タイプのサービスの場合、フォーマットは `<アプリケーション名>-ack-ingress-nginx-v1-controller-internal` です。全体の長さが 63 文字を超えると、リソースの作成に失敗します。
グラフ	ack-ingress-nginx-v1 を検索して選択します。 ack-ingress-nginx チャートはメンテナンスが終了しています。
Chart バージョン	バージョン 1.24 以降のクラスターの場合：4.0.22 以降。バージョン 1.22 のクラスターの場合：4.0.16 (含む) から 4.0.22 (含まない) までのバージョン。
パラメーター	デフォルトでは、NGINX Ingress コントローラーは 2 つのレプリカを持つ Deployment としてデプロイされます。このコントローラーは、LoadBalancer タイプのインターネット向けサービスを自動的に作成し、トラフィックエントリポイントとして CLB インスタンスをバインドします。デフォルト構成を調整するには、「ack-ingress-nginx-v1 のパラメーター」をご参照ください。この例では、後続のステップで検証するために内部向けコントローラーをデプロイします。デプロイ中に、`controller.service.external.enabled` を `false` に、`controller.service.internal.enabled` を `true` に設定します。重要複数のコントローラーをデプロイする場合、IngressClass 名の競合を避けるために、controller.ingressClassResource.name と controller.ingressClassResource.controllerValue の値がクラスター内で一意であることを確認してください。

コントローラーが作成された後、Helm ページでその情報を表示します。基本情報 セクションで、その 名前空間 をメモしておきます。リソース セクションで、後の検証のために IngressClass 名と Service 名をメモしておきます。

トラフィック隔離の検証

以下の手順では、インターネット向けと内部向けのトラフィックを分離するシナリオをシミュレートして、トラフィックの隔離を検証します。

デフォルトコントローラー：アドオン管理 ページからデプロイされた NGINX Ingress コントローラーがクラスターにすでに存在します。これはインターネット向け SLB インスタンスにバインドされ、インターネット向けのエントリポイントを提供します。

これが構成されていない場合は、「NGINX Ingress を作成してサービスを公開する」をご参照ください。
新しいコントローラー：前の手順で作成した新しいコントローラーは、内部向け SLB インスタンスにバインドされ、VPC 内でのみサービスを提供します。

以下の手順では、サンプルアプリケーションをデプロイし、新しいコントローラーのみを対象とする Ingress ルールを作成して、隔離が有効であることを検証します。

ステップ 1：テストアプリケーションのデプロイ

nginx.yaml ファイルを作成します。

以下の例では、NGINX アプリケーションとその Service をデプロイします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
        imagePullPolicy: Always
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  sessionAffinity: None
  type: NodePort

サンプルアプリケーションをデプロイします。
```
kubectl apply -f nginx.yaml
```

ステップ 2：Ingress ルールの作成とバインド

ingress.yaml ファイルを作成します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx
spec:
  # 値を、以前に設定した IngressClass 名 (controller.ingressClassResource.name) に変更します。
  ingressClassName: "<YOUR_INGRESS_CLASS>"
  rules:
  # 以下のドメイン名はテスト用です。本番環境では実際のドメイン名に置き換えてください。
  - host: foo.bar.com
    http:
      paths:
      - path: /
        backend:
          service: 
            name: nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Ingress ルールを作成します。
```
kubectl apply -f ingress.yaml
```

ステップ 3：アクセスのテスト

各コントローラーの SLB の IP アドレスを取得します。

デフォルトのインターネット向けコントローラーの SLB の IP アドレス：

PUBLIC_IP=$(kubectl get svc -n kube-system nginx-ingress-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo "Public Ingress IP: $PUBLIC_IP"

新しい内部向けコントローラーの SLB の IP アドレス：

# <YourNamespace> を新しいコントローラーの名前空間 (例：default) に置き換えます。
# <YourChartName> を新しいコントローラーのアプリケーション名 (リリース名) に置き換えます。
INTERNAL_IP=$(kubectl get svc -n <YourNamespace> <YourChartName>-ack-ingress-nginx-v1-controller-internal -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo "Internal Ingress IP: $INTERNAL_IP"

内部向けコントローラー経由でアプリケーションにアクセスします (成功する見込み)。

VPC 内のターミナルにログインし、次のコマンドを実行します。ステータスコード 200 が返されれば、内部向けコントローラーがトラフィックを正しくルーティングしていることが確認できます。
```
# 実際の内部 IP アドレスに置き換えます。
curl -o /dev/null -s -w "%{http_code}\n" -H "Host: foo.bar.com" http://$INTERNAL_IP
```
インターネット向けコントローラー経由でアプリケーションにアクセスします (失敗する見込み)。

curl コマンドを実行します。404 Not Found という応答が返されれば、インターネット向けコントローラーが Ingress ルールを無視したこと、つまりトラフィックの隔離が機能していることが確認できます。
```
# 実際のインターネット向け IP アドレスに置き換えます。
curl -H "Host: foo.bar.com" http://$PUBLIC_IP
```

本番環境へのデプロイ

リソース計画：高可用性を確保するために、以下のチャートパラメーターを検討してください。
- 複数のレプリカを構成する：controller.replicaCount
- 適切なリソースリクエストとリミットを設定する：controller.resources.requests および controller.resources.limits
- Pod のアンチアフィニティを構成する：controller.affinity フィールドの下に podAntiAffinity ルールを追加して、Pod を異なるノードにスケジュールします。
モニタリングとアラート：controller.metrics.enabled: true を設定してメトリクスを有効にし、controller.metrics.serviceMonitor.enabled: true を設定して ServiceMonitor を有効にします。これらを Prometheus モニタリングシステムと統合します。リクエストレイテンシー、エラー率 (HTTP 4xx/5xx) などの主要なメトリクスに注目し、アラートルールを構成します。
パフォーマンスの最適化：高性能、低レイテンシーのシナリオでは、Service 構成で Network Load Balancer (NLB) インスタンスを使用することを推奨します。
- 内部向けサービス：controller.service.internal.loadBalancerClass: "alibabacloud.com/nlb"
- インターネット向けサービス：controller.service.loadBalancerClass: "alibabacloud.com/nlb"
バージョンのメンテナンス：
- NGINX Ingress コントローラーコンポーネントのリリースノートに従って、セキュリティ修正をタイムリーに適用してください。
- より強力な隔離を実現するために、Network Policy を使用して各 Ingress コントローラーがアクセスできるバックエンドサービスを制限します。

付録：主要なコンポーネントパラメーター

パラメーター	説明
`controller.image.repository`	NGINX Ingress コントローラーのイメージリポジトリ。
`controller.image.tag`	NGINX Ingress コントローラーのイメージバージョン。
`controller.ingressClassResource.name`	クラスター内で IngressClass リソースに付ける一意の名前。この名前は、デフォルトコントローラーの識別子である `nginx` にすることはできません。
`controller.ingressClassResource.controllerValue`	この Ingress コントローラーの一意のコントローラークラス値。この値は、デフォルトコントローラーの識別子である `k8s.io/ingress-nginx` にすることはできません。
`controller.replicaCount`	Ingress コントローラーの Pod レプリカの数。高可用性のために 2 以上に設定することを推奨します。
`controller.service.enabled`	コントローラーを公開するために LoadBalancer タイプのサービス (インターネット向けまたは内部向け) を作成するかどうかを指定します。
`controller.service.external.enabled`	`true` に設定すると、インターネット向けのエントリポイントを公開するためにインターネット向け SLB サービスが作成されます。
`controller.service.internal.enabled`	`true` に設定すると、VPC 内でのみサービスを提供するために内部向け SLB サービスが作成されます。
`controller.kind`	Ingress コントローラーのデプロイモード：`Deployment` または `DaemonSet`。
`controller.electionID`	コントローラーレプリカ間のリーダー選出に使用される識別子。リーダーのみが Ingress リソースのステータスを更新できます。同じ名前空間に複数の Ingress コントローラーをデプロイする場合、この値は一意である必要があります。
`controller.metrics.enabled`	`true` に設定すると、Ingress コントローラーの Prometheus メトリクスエンドポイントが有効になります。
`controller.metrics.serviceMonitor.enabled`	`true` に設定すると、ServiceMonitor リソースが作成され、Prometheus がメトリクスを自動的に検出してスクレイプできるようになります。 `controller.metrics.enabled` が `true` に設定されている場合にこのオプションを有効にすることを推奨します。
`controller.service.loadBalancerClass`	インターネット向けサービスを作成する際に使用する SLB インスタンスのタイプ。 `"alibabacloud.com/clb"` (デフォルト)：Classic Load Balancer (CLB) インスタンスを使用します。 `"alibabacloud.com/nlb"`：Network Load Balancer (NLB) インスタンスを使用します。
`controller.service.internal.loadBalancerClass`	内部向けサービスを作成する際に使用する SLB インスタンスのタイプ。 `"alibabacloud.com/clb"` (デフォルト)：CLB インスタンスを使用します。 `"alibabacloud.com/nlb"`：NLB インスタンスを使用します。