Versão 1.10

Como configurar o plano de controle gerenciado pelo Google

Visão geral

O plano de controle do Anthos Service Mesh gerenciado pelo Google é um serviço gerenciado do Google Cloud que você precisa apenas configurar. O Google gerencia a confiabilidade, os upgrades, o escalonamento e a segurança para você de maneira compatível com versões anteriores. Neste guia, explicamos como configurar ou migrar aplicativos para o plano de controle gerenciado pelo Google em uma configuração de um ou vários clusters.

É possível usar um único plano de controle gerenciado pelo Google para vários clusters do GKE em um único projeto do Google Cloud.

Para saber mais sobre os recursos compatíveis e as limitações do plano de controle gerenciado do Anthos Service Mesh, consulte Recursos compatíveis com o plano de controle do Anthos Service Mesh gerenciado pelo Google.

Pré-requisitos

Veja o que é necessário para seguir este guia:

Se a Identidade da carga de trabalho não estiver ativada, é possível ativá-la usando o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --zone LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

Faça o download do script de instalação

  1. Faça o download da última versão do script que instala o Anthos Service Mesh 1.10.4 no diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asm
    
  2. Faça o download do SHA-256 do arquivo para o diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10.sha256 > install_asm.sha256
    
  3. Com os dois arquivos no mesmo diretório, verifique o download:

    sha256sum -c --ignore-missing install_asm.sha256
    

    Quando a verificação acabar, o comando gerará: install_asm: OK

    Para compatibilidade, o arquivo install_asm.sha256 inclui a soma de verificação duas vezes para permitir que qualquer versão do script seja renomeada como install_asm. Se você receber um erro informando que --ignore-missing não existe, execute novamente o comando anterior sem a sinalização --ignore-missing.

  4. Torne o script executável:

    chmod +x install_asm
    

Configurar cada cluster

Siga as etapas a seguir para configurar o plano de controle gerenciado pelo Google para cada cluster na malha.

Receber credenciais do cluster

Recupere as credenciais apropriadas. O comando a seguir também apontará o contexto kubectl ao cluster de destino.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Aplicar o plano de controle gerenciado pelo Google

Execute o script de instalação para cada cluster que usará o plano de controle gerenciado pelo Google:

Se você não precisar da Interface de rede de contêineres do Istio (CNI, na sigla em inglês), omita a sinalização --option cni-managed no comando install_asm mostrado no exemplo a seguir. A CNI é uma opção para o plano de controle gerenciado pelo Google configurar a interceptação do Istio e a rede de baixo nível usando a interface CNCF CNI em vez de usar o contêiner init de alto privilégio.

./install_asm --mode install --managed \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --verbose \
    --output_dir CLUSTER_NAME \
    --enable-all \
    --option cni-managed

O script fará o download de todos os arquivos para configurar o plano de controle gerenciado no --output_dir especificado, instalando um gateway do Istio, assim como a ferramenta istioctl e os aplicativos de amostra.

Instalar os gateways do Istio (opcional)

Como alternativa, é possível instalar um ou mais gateways do Istio no cluster para lidar com o tráfego de entrada normal. Para isso, siga estas etapas:

  1. Escolha uma destas duas opções para configurar o namespace em que você implantará o gateway em etapas posteriores.

    • Ativar o namespace para injeção:
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
      

    OU

    • Ativar a injeção apenas para o pod de gateway, mas não para todos os pods no namespace. Este comando remove todos os rótulos de injeção. Posteriormente, você ativará a injeção no próprio pod:
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
      
  2. Crie uma implantação e um serviço para o gateway usando o exemplo mínimo a seguir:

    kubectl apply -f - << EOF
    apiVersion: v1
    kind: Service
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      type: LoadBalancer
      selector:
        istio: ingressgateway
      ports:
      - port: 80
        name: http
      - port: 443
        name: https
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: istio-ingressgateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      template:
        metadata:
          annotations:
            # This is required to tell Anthos Service Mesh to inject the gateway with the
            # required configuration.
            inject.istio.io/templates: gateway
          labels:
            istio: ingressgateway
            istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
        spec:
          containers:
          - name: istio-proxy
            image: auto # The image will automatically update each time the pod starts.
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "watch", "list"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: istio-ingressgateway-sds
      namespace: GATEWAY_NAMESPACE
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: istio-ingressgateway-sds
    subjects:
    - kind: ServiceAccount
      name: default
    EOF
    
  3. Depois de criar a implantação, verifique se os novos serviços estão funcionando corretamente:

    kubectl get pod,service -n GATEWAY_NAMESPACE
    

    Verifique se a resposta é semelhante a esta:

    NAME                                      READY   STATUS    RESTARTS   AGE
    pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
    
    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
    service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Configurar a descoberta de endpoint (somente para instalações de vários clusters)

O plano de controle gerenciado do Anthos Service Mesh é compatível com uma configuração de projeto único, de rede única e multiprimária, com a diferença de que o plano de controle não está instalado no cluster. Uma configuração multiprimária significa que cada cluster é configurado com secrets para todos os outros clusters, o que permite que cada cluster descubra endpoints de todos os outros clusters.

Antes de continuar, é necessário executar o script de instalação em cada cluster, conforme descrito nas etapas anteriores. Não há necessidade de indicar que um cluster é um cluster primário, pois esse é o comportamento padrão.

Para cada cluster, ative a descoberta de endpoints executando os seguintes comandos uma vez para cada outro cluster i=1..N na malha:

  1. Para cada cluster, verifique se o contexto de configuração do kubectl aponta para o cluster atual:

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
    
  2. Ative a descoberta de endpoints executando os seguintes comandos uma vez para cada outro cluster i=1..N na malha:

    export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i
    
    ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
      kubectl apply -f - --context=${CTX}
    
  3. Para verificar se o secret foi criado, execute o comando:

    kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
    

    Verifique o resultado esperado:

    NAME                                   TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s
    
  4. Se o cluster atual for adicionado a uma malha de vários clusters existente, permita que todos os outros clusters descubram os endpoints. Basta criar um secret correspondente ao cluster atual em todos os outros clusters:

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
      kubectl apply -f - --context=${CTX_i}
    
  5. Também é possível verificar o secret do outro cluster:

    kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}
    

    Verifique o resultado esperado:

    NAME                            TYPE     DATA   AGE
    istio-remote-secret-CLUSTER_NAME   Opaque   1      44s
    

Para mais detalhes e um exemplo com dois clusters, consulte Ativar a descoberta de endpoints.

Implantar aplicativos

Antes de implantar aplicativos, remova os rótulos istio-injection anteriores dos namespaces e defina o rótulo istio.io/rev:asm-managed-rapid:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

Até o momento, você configurou o plano de controle gerenciado do Anthos Service Mesh. Agora está tudo pronto para implantar os aplicativos ou implantar o aplicativo de amostra Bookinfo.

Se você implantar um aplicativo em uma configuração de vários clusters, replique a configuração do Kubernetes e do plano de controle em todos os clusters, a menos que pretenda limitar essa configuração específica a um subconjunto de clusters. A configuração aplicada a um determinado cluster é a fonte da verdade desse cluster. Além disso, se o cluster também executar o Anthos Service Mesh 1.7, 1.8 ou mais recente com o Mesh CA em outros namespaces, verifique se o aplicativo pode se comunicar com os outros aplicativos controlados pelo plano de controle no cluster.

Verificar as métricas do plano de controle

Para verificar se configuração funciona corretamente:

  1. No Console do Cloud, veja as métricas do plano de controle:

    Acessar o Metrics Explorer

  2. Escolha o espaço de trabalho e adicione uma consulta personalizada usando os seguintes parâmetros:

    • Tipo de recurso: contêiner do Kubernetes
    • Métrica: clientes proxy
    • Filtro: container_name="cr-asm-managed-rapid"
    • Agrupar por: rótulo de revisão e rótulo do proxy_version
    • Soma do agregador
    • Período: 1 minuto

    Ao executar o Anthos Service Mesh com um plano de controle gerenciado pelo Google e outro no cluster, é possível diferenciar as métricas pelo nome do contêiner. Por exemplo, as métricas gerenciadas têm container_name="cr-asm-managed", enquanto métricas não gerenciadas têm container_name="discovery". Para exibir métricas de ambos, remova o filtro em container_name="cr-asm-managed".

  3. Verifique a versão do plano de controle e a versão do proxy inspecionando os seguintes campos no Metrics Explorer:

    • O campo revisão indica a versão do plano de controle.
    • O campo proxy_version indica o proxy_version.
    • O campo valor indica o número de proxies conectados.

Migrar aplicativos para o plano de controle gerenciado pelo Google

O plano de controle do Anthos Service Mesh gerenciado pelo Google é compatível apenas com a migração do Anthos Service Mesh 1.9 que usa a Mesh CA.

Para migrar para o plano de controle gerenciado pelo Google, siga estas etapas:

  1. Execute o script conforme indicado na seção Instalar o plano de controle.

  2. Substitua o rótulo de namespace atual pelo rótulo istio.io/rev:asm-managed-rapid:

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
        --overwrite
    
  3. Execute um upgrade contínuo das implantações no namespace:

    kubectl rollout restart deployment -n NAMESPACE
    
  4. Teste o aplicativo para verificar se as cargas de trabalho funcionam corretamente.

  5. Se você tiver cargas de trabalho em outros namespaces, repita os passos anteriores para cada namespace.

  6. Se você implantou o aplicativo em uma configuração de vários clusters, replique a configuração do Kubernetes e do Istio em todos os clusters, a menos você pretenda limitar essa configuração apenas a um subconjunto de clusters. A configuração aplicada a um determinado cluster é a fonte da verdade desse cluster.

  7. Verifique se as métricas aparecem conforme esperado seguindo as etapas em Verificar métricas do plano de controle.

Um cluster pode ter uma combinação de revisões. Por exemplo, Anthos Service Mesh 1.7 e 1.8 e um plano de controle no cluster juntos. É possível misturar namespaces usando diferentes revisões do plano de controle do Anthos Service Mesh indefinidamente.

Se o aplicativo funcionar como esperado, é possível remover o istiod no cluster depois de alternar todos os namespaces para o plano de controle no cluster ou mantê-los como backup. istiod reduzirá automaticamente o uso de recursos. Para remover, pule para Excluir o plano de controle antigo.

Se você encontrar problemas, identifique e resolva-os seguindo as informações em Como resolver problemas do plano de controle gerenciado. Se necessário, reverta para a versão anterior.

Excluir o plano de controle antigo

Depois de instalar e confirmar que todos os namespaces usam o plano de controle gerenciado pelo Google, é possível excluir o plano de controle antigo.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Se você usou istioctl kube-inject em vez da injeção automática ou se instalou outros gateways, verifique as métricas do plano de controle e verifique se o número de endpoints conectados é zero.

Reverter

Siga estas etapas se precisar reverter para a versão anterior do plano de controle:

  1. Atualize as cargas de trabalho a serem injetadas com a versão anterior do plano de controle: No comando a seguir, o valor de revisão asm-191-1 é usado apenas como exemplo. Substitua o valor de exemplo pelo rótulo da revisão do plano de controle anterior.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. Reinicie os pods para acionar a reinjeção para que os proxies tenham a versão anterior:

    kubectl rollout restart deployment -n NAMESPACE
    

O plano de controle gerenciado será escalonado automaticamente para zero e não usará nenhum recurso quando não estiver em uso. Os webhooks e o provisionamento mutáveis não serão afetados e não afetarão o comportamento do cluster.

O gateway agora está definido para a revisão asm-managed. Para reverter, execute novamente o comando de instalação do Anthos Service Mesh, que implantará novamente o gateway que aponta para o plano de controle no cluster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Esta é a resposta esperada em caso de êxito:

deployment.apps/istio-ingressgateway rolled back

Migrar um gateway para o plano de controle gerenciado pelo Google

  1. Crie uma implantação do Kubernetes para a nova versão do gateway usando a documentação. É preciso configurar o serviço existente do gateway do Kubernetes para selecionar a versão antiga e a nova usando o campo selector na configuração do serviço.

  2. Ao usar o comando kubectl scale, faça o escalonamento gradual da nova implantação, enquanto reduz a implantação antiga e verifica os sinais de qualquer interrupção/inatividade do serviço. Se a migração for bem-sucedida, você não precisará atingir instâncias antigas sem interrupção do serviço.

Desinstalar

O plano de controle gerenciado pelo Google será escalonado automaticamente para zero quando nenhum namespace estiver sendo usado. Portanto, nenhuma desinstalação é necessária.

Solução de problemas

Para identificar e resolver problemas ao usar um plano de controle gerenciado, consulte Como resolver problemas do plano de controle gerenciado.

A seguir