Installare un controller in ingresso del gateway applicazione usando un gateway applicazione esistente

Articolo
05/08/2024

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

Suggerimento

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

Struttura

Prerequisiti
Autenticazione di Azure Resource Manager (ARM)
- Opzione 1: configurare l'identità del carico di lavoro Microsoft Entra e creare l'identità di Azure in ARM
- Opzione 2: configurare un'entità servizio
Installare il controller in ingresso usando Helm
Gateway applicazione condiviso: installare il controller in ingresso del gateway applicazione in un ambiente in cui il gateway applicazione viene condiviso tra un cluster del servizio Azure Kubernetes e/o altri componenti di Azure.

Prerequisiti

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

Un cluster del servizio Azure Kubernetes con Azure Container Networking Interface (CNI)
Gateway applicazione v2 nella stessa rete virtuale del cluster del servizio Azure Kubernetes
Identità del carico di lavoro Microsoft Entra configurata per il cluster del servizio Azure Kubernetes
Cloud Shell è l'ambiente shell di Azure, in cui sono installati l'interfaccia della riga di comando az, kubectl e helm. Questi strumenti sono necessari per i comandi usati per supportare la configurazione di questa distribuzione.

Eseguire il backup della configurazione del gateway applicazione prima di installare il controller in ingresso del gateway applicazione:

Nel portale di Azure passare all'istanza del gateway applicazione.
Nella sezione Automazione selezionare Esporta modello e quindi selezionare Scarica.

Il file ZIP scaricato contiene modelli JSON e script Bash e PowerShell che è possibile usare per ripristinare il gateway app, se necessario

Installare Helm

Helm è uno strumento di gestione pacchetti per Kubernetes, usato per installare il pacchetto application-gateway-kubernetes-ingress.

Nota

Se si usa Cloud Shell, non è necessario installare Helm. Azure Cloud Shell include Helm versione 3. Ignorare il primo passaggio e aggiungere semplicemente il repository Helm del controller in ingresso del gateway applicazione.

Installare Helm ed eseguire quanto segue per aggiungere il pacchetto Helm application-gateway-kubernetes-ingress:

Cluster del servizio Azure Kubernetes abilitato per 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

Aggiungere il repository Helm AGIC:

helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/
helm repo update

Autenticazione di Azure Resource Manager

Il controller in ingresso del gateway applicazione comunica con il server API Kubernetes e Azure Resource Manager. Richiede un'identità per accedere a queste API.

Configurare l'identità del carico di lavoro Microsoft Entra

L'identità del carico di lavoro di Microsoft Entra è un'identità assegnata a un carico di lavoro software, per autenticare e accedere ad altri servizi e risorse. Questa identità consente al pod del servizio Azure Kubernetes di usare l'identità ed eseguire l'autenticazione con altre risorse di Azure. Per questa configurazione, occorre l'autorizzazione per consentire al pod del controller in ingresso del gateway applicazione di inviare richieste HTTP ad ARM.

Usare il comando az account set dell'interfaccia della riga di comando di Azure per impostare una sottoscrizione specifica come sottoscrizione attiva corrente. Quindi, usare il comando az identity create per creare un'identità gestita. L'identità deve essere creata nel gruppo di risorse del nodo. Per impostazione predefinita, al gruppo di risorse nodo viene assegnato un nome simile a MC_myResourceGroup_myAKSCluster_eastus.
```
az account set --subscription "subscriptionID"
```
```
az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"
```

Per l'assegnazione di ruolo, eseguire il comando seguente per identificare il valore di principalId per l'identità appena creata:

$resourceGroup="resource-group-name"
$identityName="identity-name"
az identity list -g $resourceGroup --query "[?name == '$identityName'].principalId | [0]" -o tsv

Concedere all'identità l'accesso Collaboratore al gateway applicazione. È necessario l'ID del gateway applicazione, che ha un aspetto simile al seguente: /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

Concedere all'identità l'accesso Lettore al gruppo di risorse del gateway applicazione. L'ID del gruppo di risorse ha un aspetto simile al seguente: /subscriptions/A/resourceGroups/B. È possibile ottenere tutti i gruppi di risorse con: 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 dal controller in ingresso del gateway applicazione disponga dell'autorizzazione Microsoft.Network/virtualNetworks/subnets/join/action delegata alla subnet in cui viene distribuito il gateway applicazione. Se non è definito un ruolo personalizzato con questa autorizzazione, è possibile usare il ruolo predefinito Collaboratore Rete, che contiene l'autorizzazione Microsoft.Network/virtualNetworks/subnets/join/action.

Uso di un'entità servizio

È anche possibile fornire al controller in ingresso del gateway applicazione l'accesso ad ARM usando un segreto Kubernetes.

Creare un'entità servizio di Azure Active Directory e applicare una codifica 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
```
Aggiungere il BLOB JSON con codifica Base64 al file helm-config.yaml. Per altre informazioni su helm-config.yaml, vedere la sezione successiva.
```
armAuth:
    type: servicePrincipal
    secretJSON: <Base64-Encoded-Credentials>
```

Distribuire il componente aggiuntivo Controller in ingresso del gateway applicazione di Azure

Creare un manifesto di distribuzione del controller in ingresso

---
# file: pet-supplies-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pet-supplies-ingress
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway

spec:
  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 in ingresso come grafico Helm

Nei primi passaggi viene installato Tiller di Helm nel cluster Kubernetes. Usare Cloud Shell per installare il pacchetto Helm del controller in ingresso del gateway applicazione:

Aggiungere il repository Helm application-gateway-kubernetes-ingress ed eseguire un'operazione helm update

helm repo add application-gateway-kubernetes-ingress https://appgwingress.blob.core.windows.net/ingress-azure-helm-package/
helm repo update

Scaricare il file helm-config.yaml, che configurerà il controller in ingresso del gateway applicazione:

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>

Modificare il file helm-config.yaml e immettere i valori per appgw e armAuth.

Nota

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

Installare il grafico Helm application-gateway-kubernetes-ingress con la configurazione helm-config.yaml del passaggio precedente

helm install -f <helm-config.yaml> application-gateway-kubernetes-ingress/ingress-azure

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

helm install ./helm/ingress-azure \
     --name ingress-azure \
     --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

Controllare il log del pod appena creato per verificare se è stato avviato correttamente

Vedere questa guida pratica per informazioni su come esporre un servizio Azure Kubernetes tramite HTTP o HTTPS a Internet usando un gateway applicazione di Azure.

Gateway applicazione condiviso

Per impostazione predefinita, il controller in ingresso del gateway applicazione assume la proprietà completa del gateway applicazione a cui è collegato. Il controller in ingresso del gateway applicazione versione 0.8.0 e successive può condividere un singolo gateway applicazione con altri componenti di Azure. Ad esempio, è possibile usare lo stesso gateway applicazione per un'app ospitata in un set di scalabilità di macchine virtuali e in un cluster del servizio Azure Kubernetes.

Eseguire il backup della configurazione del gateway applicazione prima di abilitare questa impostazione:

Nel portale di Azure passare all'istanza di Application Gateway
Nella sezione Automazione selezionare Esporta modello e quindi selezionare Scarica.

Il file ZIP scaricato contiene modelli JSON e script Bash e PowerShell che è possibile usare per ripristinare il gateway applicazione

Scenario di esempio

Si esaminerà ora un gateway applicazione immaginario, che gestisce il traffico per due siti Web:

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

Con le impostazioni predefinite, il controller in ingresso del gateway applicazione assume la proprietà completa del gateway applicazione a cui fa riferimento. Il controller in ingresso del gateway applicazione sovrascrive tutta la configurazione del gateway applicazione. Se si crea manualmente un listener per prod.contoso.com (nel gateway applicazione) senza definirlo nell'ingresso Kubernetes, il controller in ingresso del gateway applicazione elimina la configurazione prod.contoso.com entro pochi secondi.

Per installare il controller in ingresso del gateway applicazione e gestire anche prod.contoso.com dai computer del set di scalabilità di macchine virtuali, è necessario vincolare il controller in ingresso del gateway applicazione alla sola configurazione di dev.contoso.com. Questa operazione è facilitata mediante la creazione un'istanza della definizione di risorsa personalizzata (CRD) seguente:

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 oggetto AzureIngressProhibitedTarget. In questo modo, il controller in ingresso del gateway applicazione (versione 0.8.0 e successive) riconosce l'esistenza della configurazione del gateway applicazione per prod.contoso.com e indica in modo esplicito di evitare di modificare qualsiasi configurazione correlata a tale nome host.

Abilitare il vincolo con una nuova installazione del controller in ingresso del gateway applicazione

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. Nella sezione appgw: aggiungere la chiave shared 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:

Assicurarsi che la definizine di risorsa personalizzata (CRD) AzureIngressProhibitedTarget sia installata con:

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

Aggiornare Helm:

helm upgrade \
    --recreate-pods \
    -f helm-config.yaml \
    ingress-azure application-gateway-kubernetes-ingress/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, come suggerisce il nome, impedisce al controller in ingresso del gateway applicazione di modificare la configurazione per qualsiasi host e percorso. L'installazione di Helm con appgw.shared=true distribuisce il controller in ingresso del gateway applicazione, ma non apporta modifiche al gateway applicazione.

Ampliare le autorizzazioni

Poiché Helm con appgw.shared=true e il criterio prohibit-all-targets predefinito impedisce al controller in ingresso del gateway applicazione di applicare una configurazione, ampliare le autorizzazioni del controller in ingresso del gateway applicazione:

Creare un nuovo file YAML denominato AzureIngressProhibitedTarget con il frammento di codice seguente contenente 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

Solo dopo aver creato il divieto personalizzato, è possibile eliminare quello predefinito, che è troppo ampio:
```
kubectl delete AzureIngressProhibitedTarget prohibit-all-targets
```

Abilitare il vincolo per un'installazione del controller in ingresso del gateway applicazione esistente

Si supponga di avere già un cluster del servizio Azure Kubernetes operativo, il gateway applicazione e di aver configurato il controller in ingresso del gateway applicazione nel cluster. È disponibile un ingresso per prod.contoso.com e il traffico per l'ingresso viene gestito correttamente dal cluster. Si vuole aggiungere staging.contoso.com al gateway applicazione esistente, ma è necessario ospitarlo in una macchina virtuale. Si intende riutilizzare il gateway applicazione esistente e configurare manualmente un listener e i pool back-end per staging.contoso.com. Ma la modifica manuale della configurazione del gateway applicazione (usando il portale, le API ARM o Terraform) causerebbe un conflitto con i presupposti della proprietà completa del controller in ingresso del gateway applicazione. Poco dopo l'applicazione delle modifiche, il controller in ingresso del gateway applicazione le sovrascrive o le elimina.

È possibile impedire al controller in ingresso del gateway applicazione di apportare modifiche a un subset della configurazione.

Creare un nuovo file YAML denominato AzureIngressProhibitedTarget con 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

Visualizzare l'oggetto appena creato:

kubectl get AzureIngressProhibitedTargets

Modificare la configurazione del gateway applicazione dal portale di Azure: aggiungere listener, regole di routing, back-end e così via. Il nuovo oggetto creato (manually-configured-staging-environment) impedisce al controller in ingresso del gateway applicazione di sovrascrivere la configurazione del gateway applicazione correlata a staging.contoso.com.

Share via