Condividi tramite


Installare AGIC usando una distribuzione di gateway applicazione esistente

Il controller in ingresso del gateway applicazione è un pod all'interno del cluster del servizio Azure Kubernetes. AGIC monitora le risorse di ingresso di Kubernetes. Crea e applica una configurazione del gateway di app Azure in base allo stato del cluster Kubernetes.

Suggerimento

Prendere in considerazione gateway applicazione per i contenitori per la soluzione di ingresso Kubernetes. Per altre informazioni, vedere Avvio rapido: Distribuire gateway applicazione per il controller ALB dei contenitori.

Prerequisiti

Questo articolo presuppone che siano già stati installati gli strumenti e l'infrastruttura seguenti:

Aggiungere il repository Helm

Helm è un gestore di pacchetti per Kubernetes. Viene usato per installare il application-gateway-kubernetes-ingress pacchetto.

Se si usa Cloud Shell, non è necessario installare Helm. Cloud Shell include Helm versione 3. Eseguire i comandi seguenti per aggiungere il repository Helm AGIC per un cluster del servizio Azure Kubernetes abilitato con il controllo degli accessi in base al ruolo di Kubernetes:

kubectl create serviceaccount --namespace kube-system tiller-sa
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller-sa
helm init --tiller-namespace kube-system --service-account tiller-sa

Eseguire il backup della distribuzione di gateway applicazione

Prima di installare AGIC, eseguire il backup della configurazione della distribuzione di gateway applicazione:

  1. Nella portale di Azure passare alla distribuzione gateway applicazione.
  2. Nella sezione Automazione selezionare Esporta modello e quindi scarica.

Il file .zip scaricato contiene modelli JSON, script Bash e script di PowerShell che è possibile usare per ripristinare gateway applicazione, se diventa necessario un ripristino.

Configurare un'identità per l'autenticazione di Resource Manager

AGIC comunica con il server API Kubernetes e Azure Resource Manager. Richiede un'identità per accedere a queste API. È possibile usare ID dei carichi di lavoro di Microsoft Entra o un'entità servizio.

Configurare l'identità del carico di lavoro Microsoft Entra

ID dei carichi di lavoro di Microsoft Entra è un'identità assegnata a un carico di lavoro software. Questa identità consente al pod del servizio Azure Kubernetes di eseguire l'autenticazione con altre risorse di Azure.

Per questa configurazione, è necessaria l'autorizzazione per il pod AGIC per effettuare richieste HTTP ad Azure Resource Manager.

  1. Usare il comando az account set dell'interfaccia della riga di comando di Azure per impostare una sottoscrizione specifica come sottoscrizione attiva corrente:

    az account set --subscription "subscriptionID"
    

    Quindi, usare il comando az identity create per creare un'identità gestita. È necessario creare l'identità nel gruppo di risorse del nodo. Al gruppo di risorse del nodo viene assegnato un nome per impostazione predefinita, ad esempio MC_myResourceGroup_myAKSCluster_eastus.

    az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
    
  2. Per l'assegnazione di ruolo, eseguire il comando seguente per identificare il principalId valore per l'identità appena creata:

    $resourceGroup="resource-group-name"
    $identityName="identity-name"
    az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv
    
  3. Concedere all'identità l'accesso collaboratore alla distribuzione di gateway applicazione. È necessario l'ID della distribuzione gateway applicazione, simile a /subscriptions/A/resourceGroups/B/providers/Microsoft.Network/applicationGateways/C.

    Prima di tutto, ottenere l'elenco degli ID del gateway applicazione nella sottoscrizione eseguendo il comando seguente:

    az network application-gateway list --query '[].id'
    

    Per assegnare l'accesso Collaboratore all'identità, eseguire il comando seguente:

    $resourceGroup="resource-group-name"
    $identityName="identity-Name"
    # Get the Application Gateway ID
    $AppGatewayID=$(az network application-gateway list --query '[].id' -o tsv)
    $role="contributor"
    # Get the principal ID for the user-assigned identity
    $principalId=$(az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv)
    az role assignment create --assignee $principalId --role $role --scope $AppGatewayID
    
  4. Concedere all'identità l'accesso Lettore al gruppo di risorse del gateway applicazione. L'ID del gruppo di risorse è simile a /subscriptions/A/resourceGroups/B. È possibile ottenere tutti i gruppi di risorse eseguendo az group list --query '[].id'.

    $resourceGroup="resource-group-name"
    $identityName="identity-Name"
    # Get the Application Gateway resource group
    $AppGatewayResourceGroup=$(az network application-gateway list --query '[].resourceGroup' -o tsv)
    # Get the Application Gateway resource group ID
    $AppGatewayResourceGroupID=$(az group show --name $AppGatewayResourceGroup --query id -o tsv)
    $role="Reader"
    # Get the principal ID for the user-assigned identity
    $principalId=$(az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv)
    # Assign the Reader role to the user-assigned identity at the resource group scope
    az role assignment create --role $role --assignee $principalId  --scope $AppGatewayResourceGroupID
    

Nota

Assicurarsi che l'identità usata da AGIC disponga dell'autorizzazione Microsoft.Network/virtualNetworks/subnets/join/action delegata alla subnet in cui viene distribuito gateway applicazione. Se non è stato definito un ruolo personalizzato con questa autorizzazione, è possibile usare il ruolo Collaboratore rete predefinito.

Configurare un'entità servizio

È anche possibile fornire l'accesso AGIC ad Azure Resource Manager usando un segreto Kubernetes:

  1. Creare un'entità servizio Active Directory e codificarla con Base64. La codifica Base64 è necessaria per il salvataggio del BLOB JSON in Kubernetes.

    az ad sp create-for-rbac --role Contributor --sdk-auth | base64 -w0
    
  2. Aggiungere il BLOB JSON con codifica Base64 al helm-config.yaml file. Il helm-config.yaml file configura AGIC.

    armAuth:
        type: servicePrincipal
        secretJSON: <Base64-Encoded-Credentials>
    

Distribuire il componente aggiuntivo AGIC

Creare un manifesto di distribuzione per il controller di ingresso

---
# file: pet-supplies-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pet-supplies-ingress
spec:
  ingressClassName: azure-application-gateway
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: store-front
            port:
              number: 80
      - path: /order-service
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 3000
      - path: /product-service
        pathType: Prefix
        backend:
          service:
            name: product-service
            port:
              number: 3002

Distribuire il controller in ingresso

$namespace="namespace"
$file="pet-supplies-ingress.yaml"
kubectl apply -f $file -n $namespace

Installare il controller di ingresso come grafico Helm

Usare Cloud Shell per installare il pacchetto Helm del controller in ingresso del gateway applicazione:

  1. Eseguire un aggiornamento Helm:

    helm repo update
    
  2. Scaricare helm-config.yaml:

    wget https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/master/docs/examples/sample-helm-config.yaml -O helm-config.yaml
    

    In alternativa, copiare il file YAML seguente:

    # 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 must manage
    #
    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 must watch
    # 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: Azure-AD-workload-identity
    armAuth:
        type: workloadIdentity
        identityClientID:  <identityClientId>
    
    ## Alternatively you can use Service Principal credentials
    # armAuth:
    #    type: servicePrincipal
    #    secretJSON: <<Generate this value with: "az ad sp create-for-rbac --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>
    
  3. Modificare helm-config.yaml e compilare i valori per appgw e armAuth.

    Nota

    <identity-client-id>è una proprietà del valore ID dei carichi di lavoro di Microsoft Entra impostato nella sezione precedente. È possibile recuperare queste informazioni eseguendo il comando seguente: az identity show -g <resourcegroup> -n <identity-name>. In questo comando è <resourcegroup> il gruppo di risorse che ospita le risorse dell'infrastruttura correlate al cluster del servizio Azure Kubernetes, gateway applicazione e all'identità gestita.

  4. Installare il grafico Helm con la helm-config.yaml configurazione del passaggio precedente:

    helm install agic-controller oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure --version 1.7.5 -f helm-config.yaml
    

    In alternativa, è possibile combinare helm-config.yaml e il comando Helm in un unico passaggio:

    helm install oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure \
         --name agic-controller \
         --version 1.7.5 \
         --namespace default \
         --debug \
         --set appgw.name=applicationgatewayABCD \
         --set appgw.resourceGroup=your-resource-group \
         --set appgw.subscriptionId=subscription-uuid \
         --set appgw.shared=false \
         --set armAuth.type=servicePrincipal \
         --set armAuth.secretJSON=$(az ad sp create-for-rbac --role Contributor --sdk-auth | base64 -w0) \
         --set rbac.enabled=true \
         --set verbosityLevel=3 \
         --set kubernetes.watchNamespace=default \
         --set aksClusterConfiguration.apiServerAddress=aks-abcdefg.hcp.westus2.azmk8s.io
    
  5. Controllare il log del pod appena creato per verificare che sia stato avviato correttamente.

Per comprendere come esporre un servizio Servizio Azure Kubernetes a Internet tramite HTTP o HTTPS usando una distribuzione del gateway di app Azure lication, vedere questa guida pratica.

Configurare una distribuzione di gateway applicazione condivisa

Per impostazione predefinita, AGIC presuppone la proprietà completa della distribuzione gateway applicazione a cui è collegato. AGIC versione 0.8.0 e successive può condividere una singola distribuzione gateway applicazione con altri componenti di Azure. Ad esempio, è possibile usare la stessa distribuzione gateway applicazione per un'app ospitata in un set di scalabilità di macchine virtuali di Azure e in un cluster del servizio Azure Kubernetes.

Scenario di esempio

Si esaminerà ora una distribuzione immaginaria gateway applicazione che gestisce il traffico per due siti Web:

  • dev.contoso.com: ospitato in un nuovo cluster del servizio Azure Kubernetes usando gateway applicazione e AGIC.
  • prod.contoso.com: ospitato in un set di scalabilità di macchine virtuali.

Con le impostazioni predefinite, AGIC presuppone la proprietà del 100% della distribuzione gateway applicazione a cui punta. AGIC sovrascrive tutta la configurazione del gateway app. Se si crea manualmente un listener per prod.contoso.com in gateway applicazione senza definirlo nell'ingresso di Kubernetes, AGIC elimina la prod.contoso.com configurazione in pochi secondi.

Per installare AGIC e anche dai prod.contoso.com computer che usano il set di scalabilità di macchine virtuali, è necessario vincolare AGIC solo alla configurazione dev.contoso.com . È possibile facilitare questo vincolo creando un'istanza della seguente definizione di risorsa personalizzata :You facilitate this constraint by instantiating the following custom resource definition (CRD):

cat <<EOF | kubectl apply -f -
apiVersion: "appgw.ingress.k8s.io/v1"
kind: AzureIngressProhibitedTarget
metadata:
  name: prod-contoso-com
spec:
  hostname: prod.contoso.com
EOF

Il comando precedente crea un AzureIngressProhibitedTarget oggetto . Questo oggetto rende AGIC (versione 0.8.0 e successive) consapevole dell'esistenza della configurazione gateway applicazione per prod.contoso.com. Questo oggetto indica anche in modo esplicito a AGIC di evitare di modificare qualsiasi configurazione correlata a tale nome host.

Abilitare una distribuzione di gateway applicazione condivisa usando una nuova installazione AGIC

Per limitare il controller in ingresso del gateway applicazione (versione 0.8.0 e successive) a un subset della configurazione del gateway applicazione, modificare il modello helm-config.yaml. appgw: Nella sezione aggiungere una shared chiave e impostarla su true:

appgw:
    subscriptionId: <subscriptionId>    # existing field
    resourceGroup: <resourceGroupName>  # existing field
    name: <applicationGatewayName>      # existing field
    shared: true                        # Add this field to enable shared Application Gateway

Applicare le modifiche Helm:

  1. Verificare che il AzureIngressProhibitedTarget CRD sia installato:

    kubectl apply -f https://raw.githubusercontent.com/Azure/application-gateway-kubernetes-ingress/7b55ad194e7582c47589eb9e78615042e00babf3/crds/AzureIngressProhibitedTarget-v1-CRD-v1.yaml
    
  2. Aggiornare Helm:

    helm upgrade \
        --recreate-pods \
        -f helm-config.yaml \
        agic-controller
        oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure
    

A questo punto, il cluster del servizio Azure Kubernetes ha una nuova istanza di AzureIngressProhibitedTarget denominata prohibit-all-targets:

kubectl get AzureIngressProhibitedTargets prohibit-all-targets -o yaml

L'oggetto prohibit-all-targets impedisce a AGIC di modificare la configurazione per qualsiasi host e percorso. Helm installato con appgw.shared=true distribuisce AGIC, ma non apporta modifiche a gateway applicazione.

Ampliare le autorizzazioni

Poiché Helm con appgw.shared=true e il valore predefinito prohibit-all-targets blocca l'applicazione di una configurazione da parte di AGIC, è necessario ampliare le autorizzazioni AGIC:

  1. Creare un nuovo file YAML denominato AzureIngressProhibitedTarget con il frammento di codice seguente che contiene la configurazione specifica:

    cat <<EOF | kubectl apply -f -
    apiVersion: "appgw.ingress.k8s.io/v1"
    kind: AzureIngressProhibitedTarget
    metadata:
      name: your-custom-prohibitions
    spec:
      hostname: your.own-hostname.com
    EOF
    
  2. Dopo aver creato il proprio divieto personalizzato, è possibile eliminare quello predefinito, che è troppo ampio:

    kubectl delete AzureIngressProhibitedTarget prohibit-all-targets
    

Abilitare una distribuzione di gateway applicazione condivisa per un'installazione AGIC esistente

Si supponga di avere già un cluster del servizio Azure Kubernetes funzionante e una distribuzione di gateway applicazione e che sia stato configurato il gateway di accesso in ingresso nel cluster. Si dispone di un ingresso per prod.contoso.com e si gestisce correttamente il traffico dal cluster.

Si vuole aggiungere staging.contoso.com alla distribuzione gateway applicazione esistente, ma è necessario ospitarla in una macchina virtuale. Si intende riutilizzare la distribuzione gateway applicazione esistente e configurare manualmente un listener e pool back-end per staging.contoso.com. Tuttavia, la modifica manuale della configurazione gateway applicazione (usando le API di portale di Azure, Resource Manager o Terraform) è in conflitto con i presupposti di AGIC di proprietà completa. Poco dopo l'applicazione delle modifiche, AGIC sovrascrive o li elimina.

È possibile impedire a AGIC di apportare modifiche a un subset della configurazione:

  1. Creare un nuovo file YAML denominato AzureIngressProhibitedTarget usando il frammento di codice seguente:

    cat <<EOF | kubectl apply -f -
    apiVersion: "appgw.ingress.k8s.io/v1"
    kind: AzureIngressProhibitedTarget
    metadata:
      name: manually-configured-staging-environment
    spec:
      hostname: staging.contoso.com
    EOF
    
  2. Visualizzare l'oggetto appena creato:

    kubectl get AzureIngressProhibitedTargets
    
  3. Modificare la configurazione gateway applicazione dal portale di Azure. Ad esempio, aggiungere listener, regole di routing e back-end. Il nuovo oggetto creato (manually-configured-staging-environment) impedisce a AGIC di sovrascrivere la configurazione di gateway applicazione correlata a staging.contoso.com.