Configurar o ingress do Istio com a API de Gateway do Kubernetes para o serviço de Kubernetes do Azure (AKS) (versão prévia)

O complemento de malha de serviço Istio oferece suporte tanto à API de gerenciamento de tráfego de entrada do próprio Istio quanto à API do Kubernetes Gateway para gerenciamento de tráfego de entrada. Você pode usar o modelo de implantação automatizada da API do Gateway istio ou o modelo de implantação manual. Este artigo descreve como configurar o gerenciamento de tráfego de entrada para o complemento de malha de serviço Istio usando a API de Gateway do Kubernetes com o modelo de implantação automatizado.

Limitações e considerações

• O complemento da malha de serviço do Istio e a implementação da API do Gateway de roteamento de aplicativos não podem ser habilitados simultaneamente. Você deve desabilitar um primeiro e habilitar o outro em uma operação separada.
• O uso da API de Gateway do Kubernetes para gerenciamento de tráfego de saída com o complemento Istio só tem suporte para o modelo de implantação manual.
• As personalizações de ConfigMap para Gateway recursos devem estar dentro da lista de permissões de personalização de recursos. Os campos que não constam na lista de permissões são bloqueados e impedidos por meio de webhooks gerenciados pelo complemento. Consulte a política de suporte de complemento do Istio para obter mais informações sobre allowed, blocked e supported recursos.
• Configurando o acesso de entrada HTTPS a serviços HTTPS - ou seja, a passagem de Indicação de Nome do Servidor (SNI) - via recurso TLSRoute não é suportada atualmente.

Pré-requisitos

• Habilite a API de Gateway Gerenciado no cluster do AKS.
• Instale a revisão do complemento de malha de serviço Istio asm-1-26 ou superior. Siga o guia de instalação se você ainda não tiver o complemento de malha do serviço Istio instalado ou o guia de atualização se você estiver em uma revisão secundária inferior.

Definir variáveis de ambiente

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

Implantar um aplicativo de exemplo

• Primeiro, implante o aplicativo 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 o Gateway do Kubernetes e o HTTPRoute

O manifesto de exemplo cria um serviço de balanceador de carga de entrada externo acessível 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.

• Implante uma configuração de API de Gateway no default namespace com o gatewayClassName definido como istio e um HTTPRoute que roteia 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 padrão, o plano de controle do Istio acrescentará o GatewayClass nome istio ao nome dos recursos que ele provisiona para o Gateway. Você pode anotar o seu recurso Gateway com gateway.istio.io/name-override para sobrescrever o nome dos recursos provisionados. Os nomes de recurso devem ser menores que 63 caracteres e devem ser um nome DNS válido.

  Observação

  Se você estiver executando uma atualização de revisão menor e tiver duas revisões de complemento de malha de serviço Istio instaladas no cluster simultaneamente, o plano de controle para a revisão de menor atualização mais recente assumirá a propriedade do Gateways por padrão. 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, verifique se ele foi atualizado para a revisão apropriada do painel de controle antes de reverter ou concluir a operação de atualização.

Verificar a criação de recursos

• Verifique se os Deploymentrecursos e os ServiceHorizontalPodAutoscalerPodDisruptionBudgetrecursos 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 solicitação para um aplicativo de exemplo

1. Tente enviar uma curl solicitação para o httpbin aplicativo. 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 uma solicitação HTTP para httpbin.

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

   Na saída, você deve ver uma resposta HTTP 200.

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

O complemento de malha de serviço Istio dá suporte à sincronização de segredos do Azure Key Vault para proteger o tráfego de entrada baseado em API do Gateway com a terminação de Transport Layer Security (TLS). Nas seções a seguir, você sincroniza segredos de Azure Key Vault no cluster do AKS usando o provedor Azure Key Vault para o complemento de driver csi (Interface de Armazenamento de Contêineres) do Repositório de Segredos e termina o TLS no gateway de entrada.

Criar chaves e certificados de cliente/servidor

1. Crie um certificado raiz e uma chave privada para assinar os certificados dos 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 Azure Key Vault e criar segredos

1. Crie uma instância Azure Key Vault para fornecer o certificado e as entradas de chave para o complemento de malha de serviço do Istio usando o comando az keyvault create. Se você já tiver uma instância Azure Key Vault, ignore esta etapa.

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

2. Habilite o Azure Key Vault provedor para o complemento de Driver do CSI (Repositório de Segredos) em seu 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 Key Vault usar o controle de acesso baseado em função do Azure (RBAC) para o modelo de permissões, siga as instruções em Grant Access a Chaves, Certificados e Segredos do Azure Key Vault com Controle de Acesso Baseado em Função do Azure para atribuir uma função do Azure de Key Vault Secrets User à identidade gerenciada atribuída pelo usuário para o suplemento. Alternativamente, se o cofre de chaves usar o modelo de permissões de política de acesso do cofre, autorize a identidade gerenciada atribuída ao usuário do complemento a acessar o recurso do Azure Key Vault usando a 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. Crie segredos em Azure Key Vault usando os certificados e chaves usando 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
   

Implantar SecretProviderClass e pod de exemplo

1. Implante o SecretProviderClass para fornecer Azure Key Vault parâmetros específicos para o driver CSI usando o manifesto a seguir. 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

   Como alternativa, para fazer referência a um tipo de objeto de certificado diretamente de Azure Key Vault, use o manifesto a seguir para implantar SecretProviderClass. Neste exemplo, test-httpbin-cert-pfx é o nome do objeto de 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. Implante um pod de exemplo usando o manifesto a seguir. O provedor do Azure Key Vault para o complemento do Driver CSI (Secrets Store) requer um pod para fazer referência apropriadamente ao 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 a criação de segredo do 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
  

Implantar gateway do TLS

1. Crie um Gateway do Kubernetes que faça referência ao segredo httpbin-credential do 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 SecretProviderClass.

2. Crie um correspondente HTTPRoute para configurar o roteamento de tráfego de entrada para o serviço httpbin sobre 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 do gateway de entrada e a porta segura 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 uma solicitação HTTPS para acessar o 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 retorna 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. Essa configuração instrui o gateway a passar o tráfego de entrada como está, sem encerrar o TLS.

Personalizações de anotação

Você pode adicionar anotações spec.infrastructure.annotations abaixo para definir as configurações do balanceador de carga para o Gateway. Por exemplo, para criar um balanceador de carga interno anexado a uma sub-rede específica, você pode criar uma 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 de ConfigMap

O complemento de malha de serviço Istio oferece suporte à personalização dos recursos gerados para o Gateways, incluindo:

• Service
• Implantação
• Escalador Automático de Pod Horizontal (HPA)
• PDB (Orçamento de Interrupção de Pod)

As configurações padrão desses recursos são definidas no ConfigMap istio-gateway-class-defaults no namespace aks-istio-system, que é provisionado pelo AKS quando os CRDs da API do Gateway Gerenciado são habilitados juntamente com o complemento do 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 para todos os Gateways com spec.gatewayClassName: istio. O ConfigMap de nível GatewayClass é instalado por padrão no namespace aks-istio-system quando a instalação da API de Gateway Gerenciado estiver habilitada. Pode levar até cinco minutos para que o istio-gateway-class-defaults ConfigMap seja implantado depois de instalar os CRDs da API do Gateway Gerenciado.

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

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

Você pode modificar essas configurações para todo o Istio Gateways em um GatewayClass nível atualizando o istio-gateway-class-defaults ConfigMap ou pode defini-las para recursos individuais Gateway . Tanto para o GatewayClass-nível quanto para Gateway-nível ConfigMaps, você deve adicionar campos à lista de permissões para o recurso em questão. Se houver personalizações tanto para o GatewayClass quanto para um Gateway individual, a configuração de nível do Gateway terá precedência.

A personalização da implantação permite campos de lista.

Campos da lista de permissões de personalização de serviço

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

A personalização de PDB (PodDisruptionBudget) permite campos de lista

Definir configurações no nível do GatewayClass

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

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

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

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

   Observação

   Somente um ConfigMap por GatewayClass é permitido.

3. Agora, você deve ver o HPA para httpbin-gateway que você criou anteriormente ser atualizado com os novos valores mínimos/máximos. Verifique as HPA configuraçõ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 Deployment foi 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. Aplique a atualização usando o kubectl apply comando.

   kubectl apply -f httpbin-gateway-updated.yaml
   

4. Verifique se o HPA valor está atualizado com os novos valores mínimos/máximos usando o kubectl get hpa comando. Se você também tiver configurado o ConfigMap no nível GatewayClass, as configurações no nível Gateway deverão ter precedência.

   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 os Deployment rótulos para garantir que o test.azureservicemesh.io/deployment-config seja 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
   

Habilitar logs de acesso para os pods do Gateway

Telemetry Os CRDs são instalados automaticamente com o complemento Istio. Você pode usar o Telemetry API para configurar o log de acesso dos pods Gateway.

Crie o recurso no aks-istio-system namespace para habilitar logs de acesso para todos os pods de Gateway na malha ou em um namespace específico para habilitar logs de acesso somente para os pods de Gateway nesse namespace.

O exemplo a seguir mostra um Telemetry recurso que habilita Gateway o registro em log de acesso:

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

Limpar os recursos

Se você não precisar mais dos recursos criados neste artigo, poderá excluí-los para evitar incorrer em encargos.

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

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

2. Se você criou um ConfigMap para personalizar os recursos do Gateway, exclua-o usando o kubectl delete configmap comando.

   kubectl delete configmap gw-options
   

3. Se você criou um SecretProviderClass e um segredo a ser usado para a terminação TLS, exclua 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