Configurar o ingress do Istio com a API Gateway do Kubernetes para o Azure Kubernetes Service (AKS)

O complemento de malha de serviços Istio suporta tanto a própria API de gestão de tráfego de entrada do Istio como a API Kubernetes Gateway para gestão de tráfego de entrada. Pode usar o modelo de implementação automatizada da API Istio Gateway ou o modelo de implementação manual. Este artigo descreve como configurar a gestão do tráfego de entrada para o complemento de malha de serviços Istio usando a API Kubernetes Gateway com o modelo de implementação automatizada.

Limitações e considerações

• O complemento de malha de serviço Istio e a implementação da Gateway API de roteamento de aplicações não podem ser ativados simultaneamente. Deves desativar um primeiro e ativar o outro numa operação separada.
• O uso da API do Kubernetes Gateway para gerenciamento de tráfego de saída com o complemento Istio só é suportado para o modelo de implantação manual.
• As personalizações do ConfigMap para Gateway recursos devem constar na lista de permissões para personalização de recursos. Campos que não estão na lista de autorização são proibidos e bloqueados através de webhooks geridos por complementos. Consulte a política de suporte a complementos do Istio para mais informações sobre allowed, blocked, e supported funcionalidades.
• A configuração do acesso de ingresso HTTPS a serviços HTTPS — ou seja, encaminhamento SNI (Server Name Indication) — através do recurso TLSRoute não é suportada na revisão asm-1-29 do add-on de malha de serviços Istio. O suporte para o recurso TLSRoute estará disponível para a revisão asm-1-30 do add-on de malha de serviço Istio e posteriores.
• A injeção de sidecars não geridos pela Microsoft (por exemplo, telemetria personalizada, registo ou agentes de segurança) nos pods proxy do gateway de entrada do Istio geridos pelo add-on não é oficialmente suportado. Se optar por injetar o seu próprio sidecar num proxy pod gerido, a Microsoft oferece apenas suporte de melhor esforço para quaisquer problemas que encontre.

Pré-requisitos

• Ativa a API do Gateway Gerido no teu cluster AKS.
• Instala a extensão de revisão asm-1-26 ou superior da malha de serviço Istio. Siga o guia de instalação caso ainda não tenha instalado o complemento da malha de serviço Istio, ou o guia de atualização se estiver numa revisão menor.

Definir variáveis de ambiente

Defina as seguintes variáveis de ambiente a utilizar ao longo deste artigo:

Implementar aplicação de exemplo

• Primeiro, implante a aplicação de exemplo httpbin no default namespace usando o kubectl apply comando.

  export ISTIO_RELEASE="release-1.27"
  kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_RELEASE/samples/httpbin/httpbin.yaml
  

Criar Gateway Kubernetes e HTTPRoute

O manifesto de exemplo cria um serviço de balanceador de carga de entrada externo acessível a partir de fora do cluster. Você pode adicionar anotações para criar um balanceador de carga interno e personalizar outras configurações do balanceador de carga.

• Implemente uma configuração de API de Gateway no namespace default com o gatewayClassName definido como istio e um HTTPRoute que encaminhe o tráfego para o serviço httpbin usando o seguinte manifesto:

  kubectl apply -f - <<EOF
  apiVersion: gateway.networking.k8s.io/v1
  kind: Gateway
  metadata:
    name: httpbin-gateway
  spec:
    gatewayClassName: istio
    listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: Same
  ---
  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: httpbin
  spec:
    parentRefs:
    - name: httpbin-gateway
    hostnames: ["httpbin.example.com"]
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /get
      backendRefs:
      - name: httpbin
        port: 8000
  EOF
  

  Observação

  Por defeito, o plano de controlo do Istio irá adicionar o GatewayClass nome istio ao nome dos recursos que provisiona para o Gateway. Pode anotar o seu Gateway recurso com o gateway.istio.io/name-override para substituir o nome dos recursos provisionados. Os nomes dos recursos devem ser menores que 63 caracteres e devem ser um nome DNS válido.

  Observação

  Se estiver a fazer uma atualização de revisão menor e tiver duas revisões de malha de serviço Istio instaladas simultaneamente no seu cluster, o plano de controlo para a revisão menor mais recente toma posse do Gateways por defeito. Você pode adicionar o istio.io/rev rótulo ao Gateway para controlar qual revisão do plano de controle o possui. Se você adicionar o rótulo de revisão, certifique-se de atualizá-lo de acordo com a revisão do plano de controle apropriado antes de reverter ou concluir a operação de atualização.

Verificar a criação de recursos

• Verifique se os Deployment, Service, HorizontalPodAutoscaler, e PodDisruptionBudget os recursos foram criados usando os seguintes kubectl get comandos:

  kubectl get deployment httpbin-gateway-istio
  kubectl get service httpbin-gateway-istio
  kubectl get hpa httpbin-gateway-istio
  kubectl get pdb httpbin-gateway-istio
  

  Exemplo de saída:

  # Deployment resource
  NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
  httpbin-gateway-istio   2/2     2            2           31m
  
  # Service resource
  NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)                        AGE
  httpbin-gateway-istio   LoadBalancer   10.0.65.45   <external-ip>    15021:32053/TCP,80:31587/TCP   33m
  
  # HPA resource
  NAME                    REFERENCE                          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
  httpbin-gateway-istio   Deployment/httpbin-gateway-istio   cpu: 3%/80%   2         5         3          34m
  
  # PDB resource
  NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
  httpbin-gateway-istio   1               N/A               2                     36m
  

Enviar pedido para aplicação de exemplo

1. Tenta enviar um curl pedido para a httpbin aplicação. Primeiro, defina a variável de INGRESS_HOST ambiente:

   kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway
   export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -ojsonpath='{.status.addresses[0].value}')
   

2. Tente enviar um pedido HTTP para httpbin.

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

   No resultado, deverá ver uma resposta HTTP 200.

Proteja o tráfego de entrada do Istio com a API Kubernetes Gateway

O complemento de malha de serviço Istio suporta a sincronização de segredos de Azure Key Vault para proteger o tráfego de entrada baseado em API de Gateway com terminação Transport Layer Security (TLS). Nas secções seguintes, sincroniza segredos do Azure Key Vault para o seu cluster AKS usando o fornecedor Azure Key Vault para o add-on Secrets Store Container Storage Interface (CSI) Driver e termina a conexão TLS no gateway de entrada.

Criar certificados e chaves cliente/servidor

1. Crie um certificado raiz e uma chave privada para assinar os certificados para serviços de exemplo:

   mkdir httpbin_certs
   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout httpbin_certs/example.com.key -out httpbin_certs/example.com.crt
   

2. Gerar um certificado e uma chave privada para httpbin.example.com:

   openssl req -out httpbin_certs/httpbin.example.com.csr -newkey rsa:2048 -nodes -keyout httpbin_certs/httpbin.example.com.key -subj "/CN=httpbin.example.com/O=httpbin organization"
   openssl x509 -req -sha256 -days 365 -CA httpbin_certs/example.com.crt -CAkey httpbin_certs/example.com.key -set_serial 0 -in httpbin_certs/httpbin.example.com.csr -out httpbin_certs/httpbin.example.com.crt
   

Configurar o Azure Key Vault e criar segredos

1. Crie uma instância Azure Key Vault para fornecer o certificado e as entradas de chave ao complemento de malha de serviço Istio usando o comando az keyvault create. Se já tens uma instância do Azure Key Vault, podes saltar este passo.

   az keyvault create --name $KEY_VAULT_NAME --resource-group $RESOURCE_GROUP --location $LOCATION
   

2. Ativa o fornecedor Azure Key Vault para o add-on Secrets Store (CSI) Driver no teu cluster usando o comando az aks enable-addons.

   az aks enable-addons --addons azure-keyvault-secrets-provider --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
   

3. Se o seu key vault usar o controlo de acesso baseado em funções do Azure (RBAC) para o modelo de permissões, siga as instruções em Providenciar acesso a chaves, certificados e segredos do Azure Key Vault com controlo de acesso baseado em funções do Azure para atribuir à identidade gerida atribuída pelo utilizador do complemento um papel de Key Vault Secrets User. Alternativamente, se o seu cofre de chaves usar o modelo de permissões da política de acesso ao cofre, autorize a identidade gerida atribuída pelo utilizador para o complemento a aceder ao recurso Azure Key Vault através da política de acesso com o comando az keyvault set-policy.

   OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.objectId' -o tsv | tr -d '\r')
   CLIENT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.clientId')
   TENANT_ID=$(az keyvault show --resource-group $RESOURCE_GROUP --name $KEY_VAULT_NAME --query 'properties.tenantId')
   
   az keyvault set-policy --name $KEY_VAULT_NAME --object-id $OBJECT_ID --secret-permissions get list
   

4. Criar segredos em Azure Key Vault usando os certificados e chaves com os seguintes comandos az keyvault secret set:

   az keyvault secret set --vault-name $KEY_VAULT_NAME --name test-httpbin-key --file httpbin_certs/httpbin.example.com.key
   az keyvault secret set --vault-name $KEY_VAULT_NAME --name test-httpbin-crt --file httpbin_certs/httpbin.example.com.crt
   

Implementar SecretProviderClass e pod de amostra

1. Implemente o SecretProviderClass para fornecer parâmetros específicos do Azure Key Vault ao driver CSI usando o seguinte manifesto. Neste exemplo, test-httpbin-key e test-httpbin-crt são os nomes dos objetos secretos em Azure Key Vault.

   cat <<EOF | kubectl apply -f -
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: httpbin-credential-spc
   spec:
     provider: azure
     secretObjects:
     - secretName: httpbin-credential
       type: kubernetes.io/tls
       data:
       - objectName: test-httpbin-key
         key: tls.key
       - objectName: test-httpbin-crt
         key: tls.crt
     parameters:
       useVMManagedIdentity: "true"
       userAssignedIdentityID: $CLIENT_ID 
       keyvaultName: $KEY_VAULT_NAME
       cloudName: ""
       objects:  |
         array:
           - |
             objectName: test-httpbin-key
             objectType: secret
             objectAlias: "test-httpbin-key"
           - |
             objectName: test-httpbin-crt
             objectType: secret
             objectAlias: "test-httpbin-crt"
       tenantId: $TENANT_ID
   EOF
   

   Observação

   Alternativamente, para referenciar um tipo de objeto certificado diretamente do Azure Key Vault, use o seguinte manifesto para implementar o SecretProviderClass. Neste exemplo, test-httpbin-cert-pfx é o nome do objeto certificado em Azure Key Vault.

   cat <<EOF | kubectl apply -f -
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: httpbin-credential-spc
   spec:
     provider: azure
     secretObjects:
     - secretName: httpbin-credential
       type: kubernetes.io/tls
       data:
       - objectName: test-httpbin-key
         key: tls.key
       - objectName: test-httpbin-crt
         key: tls.crt
     parameters:
       useVMManagedIdentity: "true"
       userAssignedIdentityID: $CLIENT_ID 
       keyvaultName: $KEY_VAULT_NAME
       cloudName: ""
       objects:  |
         array:
           - |
             objectName: test-httpbin-cert-pfx  #certificate object name from keyvault
             objectType: secret
             objectAlias: "test-httpbin-key"
           - |
             objectName: test-httpbin-cert-pfx #certificate object name from keyvault
             objectType: cert
             objectAlias: "test-httpbin-crt"
       tenantId: $TENANT_ID
   EOF
   

2. Implemente um pod de amostra usando o seguinte manifesto. A extensão do Azure Key Vault para o Secrets Store (CSI) Driver exige que um pod referencie o recurso SecretProviderClass para garantir a sincronização dos segredos do Azure Key Vault para o cluster.

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: secrets-store-sync-httpbin
   spec:
     containers:
       - name: busybox
         image: mcr.microsoft.com/oss/busybox/busybox:1.33.1
         command:
           - "/bin/sleep"
           - "10"
         volumeMounts:
         - name: secrets-store01-inline
           mountPath: "/mnt/secrets-store"
           readOnly: true
     volumes:
       - name: secrets-store01-inline
         csi:
           driver: secrets-store.csi.k8s.io
           readOnly: true
           volumeAttributes:
             secretProviderClass: "httpbin-credential-spc"
   EOF
   

Verificar criação de segredos TLS

• Verifique se o httpbin-credential segredo foi criado no default namespace conforme definido no recurso SecretProviderClass usando o kubectl describe secret comando.

  kubectl describe secret/httpbin-credential
  

  Exemplo de saída:

  Name:         httpbin-credential
  Namespace:    default
  Labels:       secrets-store.csi.k8s.io/managed=true
  Annotations:  <none>
  
  Type:  kubernetes.io/tls
  
  Data
  ====
  tls.crt:  1180 bytes
  tls.key:  1675 bytes
  

Implementar o Gateway TLS

1. Crie um Kubernetes Gateway que faça referência ao segredo httpbin-credential debaixo da configuração TLS usando o seguinte manifesto:

   cat <<EOF | kubectl apply -f -
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: httpbin-gateway
   spec:
     gatewayClassName: istio
     listeners:
     - name: https
       hostname: "httpbin.example.com"
       port: 443
       protocol: HTTPS
       tls:
         mode: Terminate
         certificateRefs:
         - name: httpbin-credential
       allowedRoutes:
         namespaces:
           from: Selector
           selector:
             matchLabels:
               kubernetes.io/metadata.name: default
   EOF
   

   Observação

   Na definição do gateway, tls.certificateRefs.name deve corresponder ao secretName recurso in SecretProviderClass.

2. Crie um correspondente HTTPRoute para configurar o encaminhamento do tráfego de entrada para o serviço httpbin através de HTTPS usando o seguinte manifesto:

   cat <<EOF | kubectl apply -f -
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: httpbin
   spec:
     parentRefs:
     - name: httpbin-gateway
     hostnames: ["httpbin.example.com"]
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /status
       - path:
           type: PathPrefix
           value: /delay
       backendRefs:
       - name: httpbin
         port: 8000
   EOF
   

3. Obtenha o endereço IP externo e a porta segura do gateway de entrada usando os seguintes comandos:

   kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway
   export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -o jsonpath='{.status.addresses[0].value}')
   export SECURE_INGRESS_PORT=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -o jsonpath='{.spec.listeners[?(@.name=="https")].port}')
   

4. Envie um pedido HTTPS para aceder ao httpbin serviço:

   curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \
   --cacert httpbin_certs/example.com.crt "https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418"
   

   A saída deve mostrar que o httpbin serviço devolve o código 418 I'm a Teapot .

   Observação

   Para configurar o acesso de entrada HTTPS a um serviço HTTPS, atualize o modo TLS na definição do gateway para Passthrough. Esta configuração instrui o gateway a passar o tráfego de entrada tal qual, sem terminar o TLS.

Personalizações de anotação

Você pode adicionar anotações em spec.infrastructure.annotations para definir as configurações do balanceador de carga para o Gateway. Por exemplo, para criar um balanceador de carga interno ligado a uma sub-rede específica, pode criar um Gateway com as seguintes anotações:

spec:
  # ... existing spec content ...
  infrastructure:
    annotations: 
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
      service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "my-subnet"

Personalizações do ConfigMap

O complemento de malha de serviços Istio suporta personalizações dos recursos gerados para o Gateways, incluindo:

• Serviço
• Implantação
• Autoscaler de pod horizontal (HPA)
• Orçamento de Interrupção de Pod (PDB)

As definições padrão para estes recursos são configuradas no istio-gateway-class-defaults ConfigMap no aks-istio-system namespace, que é provisionado pelo AKS quando os CRDs da API de Gateway Gerido estão ativados juntamente com o add-on Istio. Este ConfigMap deve ter o rótulo gateway.istio.io/defaults-for-class definido como istio para que as personalizações entrem em vigor em todos os Gateways com spec.gatewayClassName: istio. O ConfigMap de nível GatewayClass é instalado por padrão no aks-istio-system namespace quando a instalação do Managed Gateway API está habilitada. Pode demorar até cinco minutos para o istio-gateway-class-defaults ConfigMap ser implementado após a instalação dos CRDs da API do Gateway Gerido.

kubectl get configmap istio-gateway-class-defaults -n aks-istio-system -o yaml

...
data:
  horizontalPodAutoscaler: |
    spec:
      minReplicas: 2
      maxReplicas: 5
  podDisruptionBudget: |
    spec:
      minAvailable: 1
...

Podes modificar estas definições para todos os Istio Gateways ao nível de GatewayClass atualizando o istio-gateway-class-defaults ConfigMap, ou podes defini-las para recursos individuais Gateway. Para ambos os níveis GatewayClass e Gateway do ConfigMaps, deve adicionar campos à lista de permissões para o recurso indicado. Se houver personalizações tanto para o GatewayClass como para um Gateway individual, a configuração do nível Gateway tem precedência.

Campos de lista de permitir a personalização de implantação

Campos de lista de permissão para a personalização de serviços

 service: |
    spec:
       externalTrafficPolicy: Local
    metadata:
      annotations:
        service.beta.kubernetes.io/port_80_health-probe_port:
        service.beta.kubernetes.io/port_80_health-probe_protocol:
        service.beta.kubernetes.io/port_80_health-probe_request-path:

Personalização do HorizontalPodAutoscaler (HPA) permite campos de lista

Campos de lista de permissão de personalização do PodDisruptionBudget (PDB)

Definir configurações de nível de GatewayClasse

1. Atualize o ConfigMap de nível GatewayClass no namespace aks-istio-system usando kubectl edit configmap comando:

   kubectl edit cm istio-gateway-class-defaults -n aks-istio-system
   

2. Edite as definições de recursos na data secção conforme necessário. Por exemplo, para atualizar as réplicas min/max do HPA e adicionar um rótulo ao Deployment, modificar o ConfigMap da seguinte forma:

   ...
   data:
     deployment: |
       metadata:
         labels:
           test.azureservicemesh.io/deployment-config: "updated"
     horizontalPodAutoscaler: |
       spec:
         minReplicas: 3
         maxReplicas: 6
     podDisruptionBudget: |
       spec:
         minAvailable: 1
   ...
   

   Observação

   Apenas um ConfigMap por GatewayClass é permitido.

3. Agora, deverás ver o HPA e httpbin-gateway que criaste anteriormente serem atualizados com os novos valores mínimos/máximos. Verifica as HPA definições usando o kubectl get hpa comando.

   kubectl get hpa httpbin-gateway-istio
   

   Exemplo de saída:

   NAME                    REFERENCE                          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
   httpbin-gateway-istio   Deployment/httpbin-gateway-istio   cpu: 3%/80%   3         6         3          36m
   

4. Verifique se o Deployment está atualizado com o novo rótulo, usando o comando kubectl get deployment.

   kubectl get deployment httpbin-gateway-istio -ojsonpath='{.metadata.labels.test\.azureservicemesh\.io\/deployment-config}'
   

   Exemplo de saída:

   updated
   

Definir configurações para um gateway específico

1. Crie um ConfigMap com personalizações de recursos para o httpbin Gateway usando o seguinte manifesto:

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: gw-options
   data:
     horizontalPodAutoscaler: |
       spec:
         minReplicas: 2
         maxReplicas: 4
     deployment: |
       metadata:
         labels:
           test.azureservicemesh.io/deployment-config: "updated-per-gateway"
   EOF
   

2. Atualize o httpbinGateway para fazer referência ao ConfigMap:

   spec:
     # ... existing spec content ...
     infrastructure:
       parametersRef:
         group: ""
         kind: ConfigMap
         name: gw-options
   

3. Aplica a atualização usando o kubectl apply comando.

   kubectl apply -f httpbin-gateway-updated.yaml
   

4. Verifica se o HPA está atualizado com os novos valores mínimos/máximos, usando o comando kubectl get hpa. Se também configurar o ConfigMap de nível GatewayClass, as definições de nível Gateway devem ter prioridade.

   kubectl get hpa httpbin-gateway-istio
   

   Exemplo de saída:

   NAME                    REFERENCE                          TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
   httpbin-gateway-istio   Deployment/httpbin-gateway-istio   cpu: 3%/80%   2         4         2          4h14m
   

5. Inspecione as Deployment etiquetas para garantir que test.azureservicemesh.io/deployment-config esteja atualizado para o novo valor usando o comando kubectl get deployment.

   kubectl get deployment httpbin-gateway-istio -ojsonpath='{.metadata.labels.test\.azureservicemesh\.io\/deployment-config}'
   

   Exemplo de saída:

   updated-per-gateway
   

Ativar registos de acesso para os pods do Gateway

Telemetry Os CRDs são instalados automaticamente com o complemento Istio. Podes usar o Telemetry API para configurar o registo de acesso para Gateway pods.

Crie o recurso no aks-istio-system namespace para permitir registos de acesso para todos os Gateway pods na malha, ou num namespace específico para permitir registos de acesso apenas para os Gateway pods nesse namespace.

O exemplo seguinte mostra um Telemetry recurso que permite Gateway o registo de acessos:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: aks-istio-system
spec:
  accessLogging:
  - providers:
    - name: envoy

Limpeza de recursos

Se já não precisar dos recursos criados neste artigo, pode eliminá-los para evitar quaisquer cobranças.

1. Elimine os recursos Gateway e HTTPRoute usando os seguintes kubectl delete comandos:

   kubectl delete gateways.gateway.networking.k8s.io httpbin-gateway
   kubectl delete httproute httpbin
   

2. Se criaste um ConfigMap para personalizar os teus recursos do Gateway, elimina-o usando o kubectl delete configmap comando.

   kubectl delete configmap gw-options
   

3. Se criou uma SecretProviderClass e um secret para a terminação de TLS, remova os recursos usando os seguintes kubectl delete comandos:

   kubectl delete secret httpbin-credential
   kubectl delete pod secrets-store-sync-httpbin
   kubectl delete secretproviderclass httpbin-credential-spc
   

Conteúdo relacionado

• Implantar gateways de saída para o complemento de malha de serviço Istio