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êinerinit
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-
- Ativar o namespace para injeção:
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:
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êmcontainer_name="discovery"
. Para exibir métricas de ambos, remova o filtro emcontainer_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.