O Anthos Service Mesh 1.11 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

Versões disponíveis

Configurar o Anthos Service Mesh gerenciado

Informações gerais

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

Para saber mais sobre os recursos e limitações compatíveis com o Anthos Service Mesh gerenciado, consulte Recursos compatíveis com o Anthos Service Mesh gerenciado.

Pré-requisitos

Como ponto de partida, neste guia presume-se que você:

um projeto do Cloud.
Uma conta de faturamento do Cloud.
O script de instalação kpt e outras ferramentas especificadas em Como instalar as ferramentas necessárias.

Requisitos

Um ou mais clusters com uma versão compatível do GKE, em uma das regiões compatíveis.
Os clusters precisam ter a Identidade da carga de trabalho ativada. Consulte Ativar a identidade da carga de trabalho para o comando gcloud.
O plano de dados gerenciados pelo Google exige que você ative o plug-in de interface de rede do contêiner (CNI, na sigla em inglês) do Istio ao implantar o plano de controle gerenciado pelo Google, conforme descrito mais adiante. página.

Migrações

As migrações/upgrades diretos do plano de controle no cluster para o plano de controle gerenciado pelo Google são compatíveis apenas com versões 1.9+ (instaladas com a CA da malha).
As instalações com a CA do Istio precisam migrar primeiro para a CA do Mesh 1.9+.
Há suporte para migrações/upgrades indiretos, ou seja, é possível seguir os caminhos de upgrade padrão do Anthos Service Mesh em cada versão até chegar a 1.11 com um plano de controle no cluster. Depois, você pode migrar para o plano de controle gerenciado pelo Google.

Limitações

Recomendamos que você analise a lista de recursos e limitações gerenciados do Anthos Service Mesh. Observe especificamente o seguinte:

O Mesh Service gerenciado pode usar vários clusters do GKE em um único projeto do Google Cloud.
A API IstioOperator não é compatível.
Limitações do plano de dados gerenciado:
- Esta versão de Visualização do plano de dados gerenciado está disponível apenas para novas implantações do plano de controle gerenciado. Se você já tiver implantado o plano de controle gerenciado e quiser implantar o plano de dados gerenciado, precisará executar novamente o script de instalação, conforme descrito em Aplicar o plano de controle gerenciado pelo Google.
- O plano de data gerenciado está disponível nos canais de lançamento Regular e Rápido.

Ativar a Identidade da carga de trabalho

Se a Identidade da carga de trabalho não estiver ativada, consulte Como ativar a identidade da carga de trabalho em um cluster para as permissões do IAM necessárias e a CLI gcloud para ativá-la.

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

Faça o download da última versão do script que instala o Anthos Service Mesh 1.11.8 no diretório de trabalho atual:
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
```
Torne o script executável:
```
chmod +x install_asm
```

Configurar cada cluster

Siga as etapas abaixo para configurar o Managed Service Mesh para cada cluster na sua 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 install_asm para cada cluster que usará o Anthos Service Mesh gerenciado. Recomendamos que você inclua as duas opções a seguir ao executar install_asm:

--option cni-managed Esta opção ativa o plug-in da interface de rede de contêiner do Istio (CNI, na sigla em inglês). O plug-in da CNI configura o redirecionamento do tráfego de rede para e de proxies sidecar usando a interface CNI da CNCF em vez de usar um contêiner init de alto privilégio.
--enable-registration Essa sinalização registra o cluster na frota.

Essas opções serão necessárias se você também quiser implantar o plano de dados gerenciado pelo Google. Veja uma lista completa de opções na página de referência do asmcli.

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --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. Nas etapas deste guia, pressupomos que você executa istioctl na raiz do diretório de instalação, com istioctl presente no subdiretório /bin dele.

Se você executar novamente install_asm no mesmo cluster, ele substituirá a configuração do plano de controle existente. Especifique as mesmas opções e sinalizações, caso queira a mesma configuração.

Observe que um gateway de entrada não é implantado automaticamente com o plano de controle. A dissociação da implantação do gateway de entrada e do plano de controle permite gerenciar mais facilmente os gateways em um ambiente de produção. Se o cluster precisar de um gateway de entrada, consulte Instalar gateways do Istio.

Aplicar o plano de dados gerenciado pelo Google

Se você quiser que o Google gerencie upgrades de proxies, ative o plano de dados gerenciado pelo Google. Se ativados, os proxies secundários e os gateways injetados são atualizados automaticamente em conjunto com o plano de controle gerenciado.

Na visualização do recurso, o plano de dados gerenciado atualiza os proxies removendo os pods que estão executando versões mais antigas do proxy. As remoções são feitas de maneira ordenada, respeitando o orçamento de interrupção do pod e controlando a taxa de alteração.

Esta versão de visualização do plano de dados gerenciado não gerencia o seguinte:

Pods não injetados.
Pods injetados manualmente usando istioctl kube-inject.
Jobs
Grupos com estado
DaemonSet

Se você não quiser usar o plano de dados gerenciado ou não quiser ativá-lo para todos os namespaces, acione uma reinicialização dos proxies para se beneficiar da imagem de proxy mais recente. O plano de controle continua a funcionar com os proxies existentes.

O plano de dados gerenciados está disponível nos canais de lançamento Rápido e Regular.

Para ativar o plano de dados gerenciado pelo Google:

Ative o gerenciamento do plano de dados:
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
Também é possível ativar o plano de dados gerenciado pelo Google para um pod específico anotando-o com a mesma anotação. Quando você anota um podPod específico, esse pod usa o proxy secundário gerenciado pelo Google, e o restante das cargas de trabalho usam os proxies secundários não gerenciados.
Repita a etapa anterior para cada namespace que você quer um plano de dados gerenciado.

Ative o Anthos Service Mesh na frota:

gcloud alpha container hub mesh enable --project=PROJECT_ID

Pode levar até dez minutos para que o controlador do plano de dados esteja pronto para gerenciar os proxies no cluster. Execute o seguinte comando para verificar o status:

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

Quando o controlador do plano de dados estiver pronto, o comando gerará a saída: Managed Data Plane is ready.

Se o status do controlador do plano de dados não for exibido depois de dez minutos, consulte Status do plano de dados gerenciado para dicas de solução de problemas.

Se você quiser desativar o plano de dados gerenciado pelo Google e voltar a gerenciar os proxies secundários, altere a anotação:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Instalar os gateways do Istio (opcional)

O Anthos Service Mesh oferece a opção de implantar e gerenciar gateways como parte da malha de serviço. Um gateway descreve um balanceador de carga operando na borda da malha que recebe conexões HTTP/TCP de entrada ou saída. Os gateways são proxies Envoy que fornecem um controle refinado sobre o tráfego que entra e sai da malha.

Como prática recomendada, crie um namespace separado para os gateways. Não implante os gateways no namespace istio-system.

É 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:

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-
```

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

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

É possível permitir que o controlador de plano de dados gerenciado gerencie os proxies para seus gateways, assim como para seus serviços. Se você implantou o plano de dados gerenciado e quer gerenciar os proxies de gateway, rotule e anote o namespace do gateway, conforme descrito em Aplicar o plano de dados gerenciado pelo Google.

Se você optar por gerenciar os gateways por conta própria, será necessário reiniciar os pods no GATEWAY_NAMESPACE quando uma nova versão do Anthos Service Mesh for lançada, para que eles escolham o novo plano de controle. configuração. Antes de reiniciar os pods, confirme se o novo plano de controle foi implementado no cluster. Para isso, verifique a versão do plano de controle usando a consulta personalizada do Metrics Explorer fornecida em Verificar o plano de controle métricas.

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

O plano de controle gerenciado do Anthos Service Mesh suporta 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.

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:

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
```

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}

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

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}
```

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

É possível ver a versão do plano de controle e do plano de dados no Metrics Explorer.

Para verificar se configuração funciona corretamente:

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

Acessar o Metrics Explorer
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".
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.
Para o canal atual para o mapeamento de versão do Mesh Service Mesh, consulte Versões do Anthos Service Mesh por canal.

Migrar aplicativos para o Anthos Service Mesh gerenciado

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

Para migrar para o Managed Service Mesh, execute as seguintes etapas:

Execute o script conforme indicado na seção Aplicar o plano de controle gerenciado pelo Google.

Se você implantou o plano de controle e o plano de dados gerenciados pelo Google:

Ative o gerenciamento do plano de dados:

kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Ative o Anthos Service Mesh na frota:

gcloud alpha container hub mesh enable --project=PROJECT_ID

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

Execute um upgrade contínuo das implantações no namespace:
```
kubectl rollout restart deployment -n NAMESPACE
```
Teste o aplicativo para verificar se as cargas de trabalho funcionam corretamente.
Se você tiver cargas de trabalho em outros namespaces, repita os passos anteriores para cada namespace.
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.
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 menos 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:

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
```
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

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.
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

Saiba mais sobre os canais de lançamento.