次の方法で共有


AGIC を使用して AKS クラスターで複数の名前空間のサポートを有効にする

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

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

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

ヒント

Kubernetes イングレス ソリューションの場合は Application Gateway for Containers を検討してください。

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

  1. 次のいずれかの方法で、helm-config.yaml ファイルを変更します。

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

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

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

競合する構成の処理

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

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

一方、AGIC は、1 つの名前空間に対してのみパス、バックエンド プール、HTTP 設定、TLS 証明書を作成し、重複を削除できます。

たとえば、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 つのイングレス リソースが同時に作成された場合、アルファベット順で先になるものが優先されます。 このプロパティに基づいて、AGIC は 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 リソースには、AGIC によって作成された名前空間 (production) の名前が含まれています。

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

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

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

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

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 accessible 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>