Freigeben über

Aktivieren der Unterstützung mehrerer Namespaces in einem AKS-Cluster mithilfe von AGIC

  • Artikel

Durch Kubernetes-Namespaces kann ein Kubernetes-Cluster partitioniert und Untergruppen eines größeren Teams zugeordnet werden. Diese untergeordneten Untergruppen können dann die Infrastruktur mit präziserer Steuerung der Ressourcen, der Sicherheit und Konfiguration usw. bereitstellen und verwalten. Kubernetes ermöglicht das unabhängige Definieren einer oder mehrerer Eingangsressourcen innerhalb der einzelnen Namespaces.

Ab Version 0.7 kann der Azure Application Gateway Kubernetes-Dateneingangscontroller (Application Gateway Ingress Controller, AGIC) Ereignisse aus mehreren Namespaces erfassen und mehrere Namespaces überwachen. Wenn ein Azure Kubernetes Service (AKS)-Administrator entscheidet, Azure Application Gateway als Eingang zu verwenden, verwenden alle Namespaces dieselbe Application Gateway-Bereitstellung. Mit einer einzigen Installation von AGIC werden die zugänglichen Namespaces überwacht und die zugeordnete Application Gateway-Bereitstellung konfiguriert.

In AGIC Version 0.7 wird weiterhin ausschließlich der Namespace default überwacht, sofern Sie dies in der Helm-Konfiguration nicht explizit in einen oder mehrere andere Namespaces ändern.

Tipp

Ziehen Sie Application Gateway für Container für Ihre Kubernetes-Eingangslösung in Betracht.

Aktivieren der Unterstützung mehrerer Namespaces

  1. Ändern Sie die Datei helm-config.yaml auf eine der folgenden Weisen:

    • Löschen Sie den watchNamespace-Schlüssel vollständig aus der Datei helm-config.yaml. AGIC berücksichtigt alle Namespaces.
    • Legen Sie watchNamespace auf eine leere Zeichenfolge fest. AGIC berücksichtigt alle Namespaces.
    • Fügen Sie mehrere durch Kommas getrennte Namespaces hinzu (z. B. watchNamespace: default,secondNamespace). AGIC berücksichtigt ausschließlich diese Namespaces.

  2. Wenden Sie Änderungen der Helm-Vorlage durch Ausführen von helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure an.

Nachdem Sie AGIC mit der Möglichkeit bereitgestellt haben, mehrere Namespaces zu beobachten, werden die folgenden Aktionen ausgeführt:

  • Auflisten von Eingangsressourcen aus allen zugänglichen Namespaces
  • Filtern nach Eingangsressourcen, die mit kubernetes.io/ingress.class: azure/application-gateway kommentiert sind
  • Erstellt eine kombinierte Application Gateway-Konfiguration
  • Wendet die Konfiguration auf die zugeordnete Application Gateway-Bereitstellung über Azure Resource Manager an

Umgang mit widersprüchlichen Konfigurationen

AGIC kann von mehreren Eingangsressourcen mit Namespaces angewiesen werden, in Konflikt stehende Konfigurationen für eine Application Gateway-Bereitstellung zu erstellen. Das heißt, zwei Eingänge könnten dieselbe Domäne beanspruchen.

An der Spitze der Hierarchie konnte AGIC Listener (IP-Adresse, Port und Host) und Routingregeln (Bindungslistener, Back-End-Pool und HTTP-Einstellungen) erstellen. Mehrere Namespaces und Eingänge könnten sie gemeinsam nutzen.

Andererseits könnte AGIC Pfade, Back-End-Pools, HTTP-Einstellungen und TLS-Zertifikate nur für einen einzigen Namespace erstellen und Duplikate entfernen.

Sehen Sie sich z. B. die folgenden doppelten Eingangsressourcen an, die in den Namespaces staging und production für www.contoso.com definiert sind:

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

Obwohl die beiden Eingangsressourcen anfordern, dass Datenverkehr für www.contoso.com an die entsprechenden Kubernetes-Namespaces weitergeleitet wird, kann nur ein Back-End den Datenverkehr verarbeiten. AGIC erstellt eine Konfiguration nach dem Prinzip „First In, First Out“ für eine der Ressourcen. Wenn zwei Eingangsressourcen gleichzeitig erstellt werden, hat diejenige, die im Alphabet weiter vorne steht, Vorrang. Basierend auf dieser Eigenschaft erstellt AGIC Einstellungen für den Eingang production. Application Gateway ist mit den folgenden Ressourcen konfiguriert:

  • Listener: fl-www.contoso.com-80
  • Routingregel: rr-www.contoso.com-80
  • Back-End-Pool: pool-production-contoso-web-service-80-bp-80
  • HTTP-Einstellungen: bp-production-contoso-web-service-80-80-websocket-ingress
  • Integritätstest: pb-production-contoso-web-service-80-websocket-ingress

Hinweis

Die erstellten Application Gateway-Ressourcen mit Ausnahme von Listener und Routingregel enthalten den Namen des Namespace (production), für den sie vom AGIC erstellt wurden.

Wenn die beiden Eingangsressourcen zu unterschiedlichen Zeitpunkten in den AKS-Cluster eingefügt werden, ist es wahrscheinlich, dass AGIC die Application Gateway-Instanz neu konfiguriert und der Datenverkehr von namespace-B an namespace-A umleitet.

Wenn Sie beispielsweise staging zuerst hinzugefügt haben, konfiguriert AGIC die Application Gateway-Instanz so, dass Datenverkehr an den Staging-Back-End-Pool weitergeleitet wird. Das Hinzufügen des production-Eingangs zu einem späteren Zeitpunkt führt dazu, dass die Application Gateway-Instanz in AGIC neu konfiguriert wird, sodass Datenverkehr an den Back-End-Pool von production weitergeleitet wird.

Beschränken des Zugriffs auf Namespaces

Standardmäßig wird Application Gateway in AGIC basierend auf einem kommentierten Eingang innerhalb eines beliebigen Namespace konfiguriert. Wenn Sie dieses Verhalten einschränken möchten, haben Sie folgende Möglichkeiten:

  • Beschränken Sie die Namespaces, indem Sie die Namespaces, die in AGIC überwacht werden sollen, über den YAML-Schlüssel watchNamespace in der Datei helm-config.yaml explizit definieren.
  • Verwenden Sie Role- und RoleBinding-Objekte, um AGIC auf bestimmte Namespaces zu beschränken.

Beispielkonfigurationsdatei für 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>

Zugehöriger Inhalt