次の方法で共有


Application Gateway イングレス コントローラーを使用して AKS クラスターでの複数の名前空間のサポートを有効にする

目的

Kubernetes 名前空間 を使用すると、Kubernetes クラスターをパーティション分割して、大規模なチームのサブグループに割り当てることが可能になります。 これらのサブチームでは、リソース、セキュリティ、構成などをより細かく制御し、インフラストラクチャをデプロイして管理できます。Kubernetes を使用すると、各名前空間内に 1 つまたは複数のイングレス リソースを個別に定義できます。

バージョン 0.7 以降の Azure Application Gateway の Kubernetes イングレス コントローラー (AGIC) では、複数の名前空間からイベントを取り込んで、それらの名前空間を監視することができます。 AKS 管理者が Application Gateway をイングレスとして使用することに決めた場合、Application Gateway の同じインスタンスがすべての名前空間で使用されます。 イングレス コントローラーの 1 回のインストールによって、アクセス可能な名前空間が監視され、関連付けられている Application Gateway が構成されます。

AGIC のバージョン 0.7 では、default 名前空間が Helm 構成内の 1 つまたは複数の異なる名前空間に明示的に変更されない限り、これが引き続き排他的に監視されます。 次のセクションを参照してください。

ヒント

また、「Application Gateway for Containers とは」も参照してください。

複数の名前空間のサポートを有効にする

複数の名前空間のサポートを有効にするには:

  1. 次のいずれかの方法で、helm-config.yaml ファイルを変更します。
    • watchNamespace キーを helm-config.yaml から完全に削除する - AGIC では、すべての名前空間が監視されます
    • watchNamespace に空の文字列を設定する - AGIC では、すべての名前空間が監視されます
    • 複数の名前空間をコンマで区切って追加する (watchNamespace: default,secondNamespace) - AGIC では、これらの名前空間が排他的に監視されます
  2. 以下を使用して、Helm テンプレートの変更を適用します。helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

複数の名前空間を監視する機能を付けてデプロイすると、AGIC によって次のアクションが実行されます。

  • アクセス可能なすべての名前空間からのイングレス リソースを一覧表示する
  • kubernetes.io/ingress.class: azure/application-gateway によって注釈が付けられたイングレス リソースにフィルター処理する
  • 組み合わせた Application Gateway 構成を作成する
  • ARM 経由で、関連付けられているアプリケーション ゲートウェイに構成を適用する

競合する構成

複数の名前空間が設定されたイングレス リソースでは、単一の Application Gateway に対して競合する構成を作成するように、AGIC に指示することができます (たとえば、同じドメインを要求する 2 つのイングレス)。

階層の最上位では、リスナー (IP アドレス、ポート、およびホスト) と ルーティング規則 (バインディング リスナー、バックエンド プール、および HTTP 設定) は、複数の名前空間/イングレスによって作成および共有することができます。

一方、パス、バックエンド プール、HTTP 設定、および TLS 証明書は、1 つの名前空間のみによって作成され、重複は削除されます。

たとえば、次の重複したイングレス リソースによって定義された www.contoso.com に対する名前空間 staging および production について考えます。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: websocket-ingress
  namespace: staging
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
    - host: www.contoso.com
      http:
        paths:
          - backend:
              serviceName: web-service
              servicePort: 80
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: websocket-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
spec:
  rules:
    - host: www.contoso.com
      http:
        paths:
          - backend:
              serviceName: web-service
              servicePort: 80

www.contoso.com がそれぞれの Kubernetes 名前空間にルーティングされるように 2 つのイングレス リソースによってトラフィックが要求されていますが、トラフィックを処理できるバックエンドは 1 つだけです。 AGIC は、リソースの 1 つに対する "最初の入力、最初の出力" に基づいて構成を作成します。 2 つのイングレス リソースが同時に作成された場合、アルファベット順で先になるものが優先されます。 このプロパティに基づいて、production イングレスの設定が作成されます。 Application Gateway は、次のリソースによって構成されます。

  • リスナー: fl-www.contoso.com-80
  • ルーティング規則: rr-www.contoso.com-80
  • バックエンド プール: pool-production-contoso-web-service-80-bp-80
  • HTTP 設定: bp-production-contoso-web-service-80-80-websocket-ingress
  • 正常性プローブ: pb-production-contoso-web-service-80-websocket-ingress

Note

リスナールーティング規則を除き、作成される Application Gateway リソースには、それらが作成された名前空間 (production) の名前が含まれています。

2 つのイングレス リソースが異なる時点で AKS クラスターに導入されている場合、AGIC では、Application Gateway が再構成され namespace-B から namespace-A にトラフィックが再ルーティングされるシナリオに終始する傾向にあります。

たとえば staging を最初に追加した場合、AGIC では、ステージング バックエンド プールにトラフィックをルーティングするように Application Gateway が構成されます。 以降の段階で、production イングレスを導入すると、AGIC では Application Gateway が再プログラミングされ、production バックエンド プールへのトラフィックのルーティングが開始されます。

名前空間へのアクセスを制限する

AGIC では既定で、いずれかの名前空間内の注釈付きのイングレスに基づいて、Application Gateway が構成されます。 この動作を制限する場合、次のオプションを使用できます。

  • AGIC において helm-config.yaml 内の watchNamespace YAML キー経由で監視する必要がある名前空間を明示的に定義することで、名前空間を制限する
  • Role/RoleBinding を使用して、AGIC を特定の名前空間に制限する

サンプルの Helm 構成ファイル

    # This file contains the essential configs for the ingress controller helm chart

    # Verbosity level of the App Gateway Ingress Controller
    verbosityLevel: 3
    
    ################################################################################
    # Specify which application gateway the ingress controller manages
    #
    appgw:
        subscriptionId: <subscriptionId>
        resourceGroup: <resourceGroupName>
        name: <applicationGatewayName>
    
        # Setting appgw.shared to "true" creates an AzureIngressProhibitedTarget CRD.
        # This prohibits AGIC from applying config for any host/path.
        # Use "kubectl get AzureIngressProhibitedTargets" to view and change this.
        shared: false
    
    ################################################################################
    # Specify which kubernetes namespace the ingress controller watches
    # Default value is "default"
    # Leaving this variable out or setting it to blank or empty string would
    # result in Ingress Controller observing all acessible namespaces.
    #
    # kubernetes:
    #   watchNamespace: <namespace>
    
    ################################################################################
    # Specify the authentication with Azure Resource Manager
    #
    # Two authentication methods are available:
    # - Option 1: AAD-Pod-Identity (https://github.com/Azure/aad-pod-identity)
    armAuth:
        type: aadPodIdentity
        identityResourceID: <identityResourceId>
        identityClientID:  <identityClientId>
    
    ## Alternatively you can use Service Principal credentials
    # armAuth:
    #    type: servicePrincipal
    #    secretJSON: <<Generate this value with: "az ad sp create-for-rbac --subscription <subscription-uuid> --role Contributor --sdk-auth | base64 -w0" >>
    
    ################################################################################
    # Specify if the cluster is Kubernetes RBAC enabled or not
    rbac:
        enabled: false # true/false
    
    # Specify aks cluster related information. THIS IS BEING DEPRECATED.
    aksClusterConfiguration:
        apiServerAddress: <aks-api-server-address>