Compartilhar via

Configurar o Ingress do Istio usando a API Gateway do Kubernetes para o AKS (Serviço de Kubernetes do Azure) (versão de pré-visualização)

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

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

Pré-requisitos

Definir variáveis de ambiente

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

Variable Description
RESOURCE_GROUP O nome do grupo de recursos que contém o cluster do AKS.
CLUSTER_NAME O nome do cluster do AKS.
LOCATION A região do Azure em que o cluster do AKS é implantado.
KEY_VAULT_NAME O nome do recurso do Azure Key Vault a ser criado para armazenar segredos do TLS. Se você tiver um recurso existente, use esse nome.

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 do Istio oferece suporte à sincronização de segredos do Azure Key Vault para proteger o tráfego de entrada baseado na API do Gateway com a Terminação TLS (Transport Layer Security). Nas seções a seguir, você sincroniza segredos do Azure Key Vault no cluster do AKS usando o provedor Azure Key Vault para o complemento do driver da Interface de Armazenamento de Contêiner (CSI) do Repositório de Segredos e encerra 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 o Azure Key Vault e criar segredos

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

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

  2. Habilite o complemento do driver do provedor Azure Key Vault para o Repositório de Segredos (CSI) 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 cofre de chaves usar o RBAC (controle de acesso baseado em função) do Azure para o modelo de permissões, siga as instruções em Fornecer acesso a chaves, certificados e segredos do Azure Key Vault com o controle de acesso baseado em função do Azure para atribuir uma função do Azure de Usuário de Segredos do Key Vault para a identidade gerenciada atribuída pelo usuário do complemento. Como alternativa, se o seu cofre de chaves usa o modelo de permissões de política de acesso ao cofre, autorize a identidade gerenciada atribuída pelo 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 no Azure Key Vault usando os certificados e as chaves usando os seguintes az keyvault secret set comandos:

    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 parâmetros específicos do Azure Key Vault 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 no 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 do Azure Key Vault, use o manifesto a seguir para implantar SecretProviderClass. Neste exemplo, test-httpbin-cert-pfx é o nome do objeto de certificado no 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 complemento do driver do provedor Azure Key Vault para o Repositório de Segredos (CSI) exige que um pod faça referência ao recurso SecretProviderClass para garantir que os segredos sejam sincronizados 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.

Observação

O ConfigMap istio-gateway-class-defaults é provisionado e reconciliado pelo AKS quando os CRDs da API do Gateway Gerenciado e o complemento do Istio estão habilitados em conjunto. Se você criou anteriormente o istio-gateway-class-defaults ConfigMap no aks-istio-system namespace por conta própria, deverá excluir a instância de ConfigMap gerida por você mesmo antes de habilitar os CRDs da API Gerenciada do Gateway para evitar conflitos com a sincronização do ConfigMap gerenciado pelo AKS.

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.

Caminho do campo Description
metadata.labels Rótulos de implantação
metadata.annotations Anotações de implantação
spec.replicas Contagem de réplicas de implantação
spec.template.metadata.labels Rótulos de pod
spec.template.metadata.annotations Anotações do Pod
spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms Afinidade de nó
spec.template.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution Afinidade de nó
spec.template.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution Afinidade de pod
spec.template.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution Afinidade de pod
spec.template.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution Antia afinidade de pod
spec.template.spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution Antia afinidade de pod
spec.template.spec.containers.resizePolicy Utilização de recursos de contêiner
spec.template.spec.containers.resources.limits Utilização de recursos de contêiner
spec.template.spec.containers.resources.requests Utilização de recursos de contêiner
spec.template.spec.containers.stdin Depuração de contêiner
spec.template.spec.containers.stdinOnce Depuração de contêiner
spec.template.spec.nodeSelector Agendamento de pods
spec.template.spec.nodeName Agendamento de pods
spec.template.spec.tolerations Agendamento de pods
spec.template.spec.topologySpreadConstraints Agendamento de pods

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

Caminho do campo Description
metadata.labels Rótulos de serviço
metadata.annotations Anotações de serviço
spec.type Tipo de serviço
spec.loadBalancerSourceRanges Configurações do balanceador de carga de serviço
spec.loadBalancerClass Configurações do balanceador de carga de serviço
spec.externalTrafficPolicy Política de tráfego de serviço
spec.internalTrafficPolicy Política de tráfego de serviço

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

Caminho do campo Description
metadata.labels Rótulos de HPA
metadata.annotations Anotações de HPA
spec.behavior.scaleUp.stabilizationWindowSeconds Comportamento de expansão do HPA
spec.behavior.scaleUp.selectPolicy Comportamento de expansão do HPA
spec.behavior.scaleUp.policies Comportamento de expansão do HPA
spec.behavior.scaleDown.stabilizationWindowSeconds Comportamento de redução vertical do HPA
spec.behavior.scaleDown.selectPolicy Comportamento de redução vertical do HPA
spec.behavior.scaleDown.policies Comportamento de redução vertical do HPA
spec.metrics Métricas de dimensionamento de recursos do HPA
spec.minReplicas Contagem mínima de réplicas HPA. Não deve estar abaixo de 2.
spec.maxReplicas Contagem máxima de réplicas do HPA

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

Caminho do campo Description
metadata.labels Rótulos PDB
metadata.annotations Anotações do PDB
spec.minAvailable Disponibilidade mínima do PDB
spec.unhealthyPodEvictionPolicy Política de remoção do PDB

Observação

Modificar a disponibilidade mínima e a política de remoção PDB pode causar erros durante as operações de atualização e exclusão de cluster ou nó. Siga o guia de solução de problemas do PDB para resolver erros UpgradeFailed devidos a falhas de remoção PDB.

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

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

  • Last updated on