Share via


Abilitare il supporto di più spazi dei nomi in un cluster del servizio Azure Kubernetes con il controller in ingresso del gateway applicazione

Motivazione

Spazi dei nomi Kubernetes consentono a un cluster Kubernetes di essere partizionato e allocato in sottogruppi di un team più grande. Questi sottoteam possono quindi distribuire e gestire l'infrastruttura con controlli più avanzati di risorse, sicurezza, configurazione e così via. Kubernetes consente di definire in modo indipendente una o più risorse di ingresso all'interno di ogni spazio dei nomi.

A partire dalla versione 0.7 il Controller in ingresso Kubernetes del gateway applicazione di Azure (AGIC) può inserire eventi da più spazi dei nomi e osservare più spazi di nomi. Se l'amministratore del servizio Azure Kubernetes decide di usare il gateway applicazione come ingresso, tutti gli spazi dei nomi usano la stessa istanza del gateway applicazione. Una singola installazione del controller in ingresso monitora gli spazi dei nomi accessibili e configura il gateway applicazione a cui è associato.

La versione 0.7 di AGIC continua a osservare esclusivamente lo spazio dei nomi default, a meno che non venga modificato in modo esplicito in uno o più spazi dei nomi diversi nella configurazione Helm. Vedere la sezione seguente.

Suggerimento

Vedere anche Che cos'è il Gateway applicativo per contenitori? al momento in anteprima pubblica.

Abilitare il supporto per più spazi dei nomi

Per abilitare il supporto per più spazi dei nomi:

  1. modificare il file helm-config.yaml in uno dei modi seguenti:
    • eliminare completamente la chiave watchNamespace da helm-config.yaml - AGIC osserva tutti gli spazi dei nomi
    • impostare watchNamespace su una stringa vuota - AGIC osserva tutti gli spazi dei nomi
    • aggiungere più spazi dei nomi separati da una virgola (watchNamespace: default,secondNamespace) - AGIC osserva esclusivamente tali spazi dei nomi
  2. applicare le modifiche del modello Helm con: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

Dopo la distribuzione con la possibilità di osservare più spazi dei nomi, AGIC esegue le azioni seguenti:

  • elenca le risorse in ingresso da tutti gli spazi dei nomi accessibili
  • filtra le risorse in ingresso annotate con kubernetes.io/ingress.class: azure/application-gateway
  • compone la configurazione del gateway applicazione combinata
  • applica la configurazione al gateway applicazione associato tramite ARM

Configurazioni in conflitto

Più risorse in ingresso con più spazi dei nomi potrebbero indicare ad AGIC di creare configurazioni in conflitto per un singolo gateway applicazione. (Ad esempio, due ingressi che sostengono lo stesso dominio).

All'inizio della gerarchia, i listener (indirizzo IP, porta e host) e le regole di gestione (listener di binding, pool back-end e impostazioni HTTP) possono essere creati e condivisi da più spazi dei nomi/ingresso.

D'altra parte, i percorsi, i pool back-end, le impostazioni HTTP e i certificati TLS possono essere creati da uno spazio dei nomi e vengono rimossi solo i duplicati.

Si considerino, ad esempio, gli spazi dei nomi in ingresso duplicati seguenti staging e production per www.contoso.com:

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

Nonostante le due risorse in ingresso che richiedono traffico per instradare www.contoso.com ai rispettivi spazi dei nomi Kubernetes, un solo back-end può gestire il traffico. AGIC crea una configurazione basata su "prima entra, prima esce" per una delle risorse. Se due risorse di ingresso vengono create contemporaneamente, quella con lettera iniziale precedente nell'alfabeto ha la precedenza. In base a questa proprietà, le impostazioni vengono create per l'ingresso production. Il gateway applicazione è configurato con le risorse seguenti:

  • Listener: fl-www.contoso.com-80
  • Regola di gestione: rr-www.contoso.com-80
  • Pool back-end: pool-production-contoso-web-service-80-bp-80
  • Impostazioni HTTP: bp-production-contoso-web-service-80-80-websocket-ingress
  • Probe di integrità: pb-production-contoso-web-service-80-websocket-ingress

Nota

Ad eccezione di listener e regola di gestione, le risorse del gateway applicazione create includono il nome dello spazio dei nomi (production) per cui sono stati creati.

Se le due risorse di ingresso vengono introdotte nel cluster del servizio Azure Kubernetes in momenti diversi, è probabile che AGIC finirà in uno scenario in cui riconfigura il gateway applicazione e reindirizza il traffico da namespace-B a namespace-A.

Ad esempio, se è stato aggiunto staging prima, AGIC configura il gateway applicazione per instradare il traffico al pool back-end di staging. In un secondo momento, l'introduzione di production in ingresso causa la riprogrammazione del gateway applicazione da parte di AGIC, che avvia il routing del traffico al pool back-end production .

Limitare l'accesso allo spazio dei nomi

Per impostazione predefinita, AGIC configura il gateway applicazione in base all'ingresso con annotazioni all'interno di qualsiasi spazio dei nomi. Se si vuole limitare questo comportamento, sono disponibili le opzioni seguenti:

  • limitare gli spazi dei nomi, se si definiscono in modo esplicito gli spazi dei nomi AGIC deve osservare tramite la chiave YAML watchNamespace in helm-config.yaml
  • usare role/roleBinding per limitare il controllo AGIC a spazi dei nomi specifici

File di configurazione Helm di esempio

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