O Anthos Service Mesh gerenciado é uma malha de serviço gerenciada pelo Google que você só precisa ativar. O Google lida com a confiabilidade, os upgrades, o escalonamento e a segurança de maneira compatível com versões anteriores.
Nesta página, mostramos como usar a API de atributos Fleet para configurar o Anthos Service Mesh gerenciado.
Ao ativar o Anthos Service Mesh gerenciado usando a API Fleet:
- O Google aplica a configuração recomendada do plano de controle
- O Google permite o gerenciamento automático do plano de dados
- Seu cluster é inscrito em um canal de lançamento do Anthos Service Mesh com base no canal de lançamento do seu cluster do Google Kubernetes Engine (GKE), e seu plano de controle e o plano de dados são atualizados a cada nova versão.
- O Google habilita a descoberta de endpoints e o balanceamento de carga entre clusters em toda a malha de serviço com as configurações padrão, embora você precise criar regras de firewall.
Use este caminho de integração se quiser:
- Usar
gcloud
para configurar o Anthos Service Mesh gerenciado usando as APIs do Google Cloud e o IAM. - Configurar o Anthos Service Mesh usando as mesmas APIs de outros recursos de frota.
- Receber automaticamente a configuração recomendada do Anthos Service Mesh em cada um de seus clusters.
Pré-requisitos
Como ponto de partida, neste guia presume-se que você:
- Um projeto do Cloud
- Uma Conta de faturamento do Cloud.
- Recebeu as permissões necessárias para provisionar o Anthos Service Mesh gerenciado
- Ativou a Identidade da carga de trabalho nos clusters.
Requisitos
- Um ou mais clusters com uma versão compatível do GKE, em uma das regiões com suporte.
- Verifique se o cluster tem capacidade suficiente para os componentes necessários que
gerenciaram as instalações do Anthos Service Mesh no cluster.
- A implantação
mdp-controller
no namespacekube-system
solicita CPU: 50m, memória: 128Mi. - O daemonset
istio-cni-node
no namespacekube-system
solicita cpu: 100m, memória: 100Mi em cada nó.
- A implantação
- Verifique se a máquina cliente da qual você instala o Anthos Service Mesh gerenciado tem conexão de rede com o servidor de API.
- Os clusters precisam estar registrados em uma frota. Ela está incluída nas instruções ou pode ser feita separadamente antes da instalação.
- O projeto precisa ter o recurso da frota Service Mesh ativado. Isso está incluído nas instruções ou pode ser feito separadamente.
O GKE Autopilot é compatível apenas com a versão 1.21.3 ou mais recente do GKE.
A CNI do Istio é necessária e instalada por padrão ao provisionar o Anthos Service Mesh gerenciado.
O Anthos Service Mesh gerenciado pode usar vários clusters do GKE em um ambiente de rede única de projeto único ou de vários projetos.
- Se você mesclar clusters que não estejam no mesmo projeto, eles vão precisar ser registrados no mesmo projeto host da frota, e será preciso que os clusters estejam em um projeto de VPC compartilhada na mesma rede.
- Para um ambiente de vários clusters com um único projeto, o projeto da frota pode ser o mesmo que o do cluster. Para mais informações sobre frotas, consulte Informações gerais das frotas.
- Para um ambiente de vários projetos, recomendamos que você hospede a frota em um projeto separado dos projetos do cluster. Se as políticas da organização e a configuração atual permitirem, recomendamos que você use o projeto da VPC compartilhada como o projeto host da frota. Para mais informações, consulte Como configurar clusters com a VPC compartilhada.
- Se a organização usa o VPC Service Controls e você está provisionando o Anthos Service Mesh gerenciado nos clusters do GKE, também é necessário seguir as etapas em VPC Service Controls para Anthos Service Mesh.
Limitações
Recomendamos que você analise a lista de recursos e limitações gerenciados do Anthos Service Mesh. Observe especificamente o seguinte:
Não há suporte para a API
IstioOperator
porque a finalidade principal dela é controlar componentes no cluster.Ativar o Anthos Service Mesh gerenciado com a API Fleet usará o Mesh CA. Se a implantação da malha de serviço envolver cargas de trabalho regulamentadas ou exigir o Certificate Authority Service (serviço de CA), siga as etapas em Provisionar o Anthos Service Mesh gerenciado usando
asmcli
.As migrações do Anthos Service Mesh gerenciado com
asmcli
para o Anthos Service Mesh com a API Fleet não são compatíveis. Da mesma forma, não é possível configurar o Anthos Service Mesh gerenciado com a API Fleet de--management manual
para--management automatic
.Nos clusters do GKE Autopilot, a configuração entre projetos é compatível apenas com o GKE 1.23 e posterior.
Para que os clusters do GKE Autopilot se adaptem ao limite de recursos do Autopilot do GKE, as solicitações e os limites de recursos de proxy padrão são definidos como 500m de CPU e 512MB de memória. É possível modificar os valores padrão usando a injeção personalizada.
Os recursos reais disponíveis no Anthos Service Mesh gerenciado dependem do canal de lançamento. Saiba mais na lista completa de recursos e limitações compatíveis com o Anthos Service Mesh.
Durante o processo de provisionamento de um plano de controle gerenciado, os CRDs do Istio correspondentes ao canal selecionado são instalados no cluster especificado. Se houver CRDs atuais do Istio no cluster, eles serão substituídos.
A CNI do Istio não é compatível com o GKE Sandbox. O Anthos Service Mesh é gerenciado no Autopilot, portanto, não funciona com o GKE Sandbox, já que a CNI gerenciada do Istio é necessária.
Antes de começar
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
- Configure o
gcloud
, mesmo que você esteja usando o Cloud Shell. -
Autentique-se com a Google Cloud CLI, em que FLEET_PROJECT_ID
é o ID do projeto host da frota. Geralmente, o FLEET_PROJECT_ID é criado por padrão e tem o mesmo nome do projeto.
gcloud auth login --project FLEET_PROJECT_ID
- Atualize os componentes:
gcloud components update
-
Ative as APIs necessárias no seu projeto do Fleet Host:
gcloud services enable mesh.googleapis.com \ --project=FLEET_PROJECT_ID
A ativação do mesh.googleapis.com ativa as seguintes APIs:
API | Finalidade | Pode ser desativada? |
---|---|---|
meshconfig.googleapis.com |
O Anthos Service Mesh usa a API Mesh Configuration para redirecionar os dados de configuração da malha para o Google Cloud. Além disso, ativar a API Mesh Configuration permite acessar as páginas do Anthos Service Mesh no console do Google Cloud e usar a autoridade de certificação do Anthos Service Mesh (Mesh CA, na sigla em inglês). | Não |
meshca.googleapis.com |
Relacionada à autoridade de certificação do Anthos Service Mesh usada pelo Anthos Service Mesh gerenciado. | Não |
container.googleapis.com |
Necessária para a criação de clusters do Google Kubernetes Engine (GKE). | Não |
gkehub.googleapis.com |
Necessária para o gerenciamento da malha como uma frota. | Não |
monitoring.googleapis.com |
Necessária para a captura da telemetria de cargas de trabalho da malha. | Não |
stackdriver.googleapis.com |
Necessária para uso da interface dos serviços. | Não |
opsconfigmonitoring.googleapis.com |
Necessária para uso da interface dos serviços para clusters fora do Google Cloud. | Não |
connectgateway.googleapis.com |
Necessária para que o plano de controle do Anthos Service Mesh gerenciado acesse cargas de trabalho da malha. | Sim* |
trafficdirector.googleapis.com |
Permite um plano de controle gerenciado altamente disponível e escalonável. | Sim* |
networkservices.googleapis.com |
Permite um plano de controle gerenciado altamente disponível e escalonável. | Sim* |
networksecurity.googleapis.com |
Permite um plano de controle gerenciado altamente disponível e escalonável. | Sim* |
Configurar o Anthos Service Mesh gerenciado
As etapas necessárias para provisionar o Anthos Service Mesh gerenciado usando a API da frota dependem da sua preferência de ativar por padrão para novos clusters de frotas ou ativá-lo por cluster.
Configurar para sua frota
Se você tiver ativado a edição Enterprise do Google Kubernetes Engine (GKE), poderá ativar o Anthos Service Mesh gerenciado como uma configuração padrão para sua frota. Isso significa que todos os novos clusters do GKE no Google Cloud registrados durante a criação do cluster terão o Anthos Service Mesh gerenciado ativado no cluster. Saiba mais sobre a configuração padrão da frota em Gerenciar recursos no nível da frota.
Para ativar os padrões da frota para o Anthos Service Mesh gerenciado, conclua as seguintes etapas:
Console
No console do Google Cloud, acesse a página Gerenciador de recursos.
No painel Malha de serviço, clique em Configurar.
Revise as configurações herdadas por todos os novos clusters criados no console do Google Cloud e registre-os na frota.
Para aplicar as configurações, clique em Configurar.
Na caixa de diálogo, clique em Confirmar.
Opcional: sincronize os clusters atuais com as configurações padrão:
- Na lista Clusters na frota, selecione os clusters que você quer sincronizar. Só é possível selecionar clusters que tenham o Anthos Service Mesh instalado.
- Clique em Sincronizar com as configurações da frota e em Confirmar na caixa de diálogo de confirmação mostrada. Esta operação leva alguns minutos para ser concluída.
gcloud
Para definir padrões no nível da frota usando a Google Cloud CLI, estabeleça as seguintes configurações:
Configurações no nível da frota
Crie um arquivo
mesh.yaml
que contenha apenas a única linhamanagement: automatic
:echo "management: automatic" > mesh.yaml
Ative o Anthos Service Mesh para sua frota:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Se você vir o erro a seguir, será necessário ativar o GKE Enterprise.
ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The [anthos.googleapis.com] service is required for this operation and is not enabled for the project [PROJECT_NUMBER]. Please use the Google Developers Console to enable it.: failed precondition
Configurações no nível do cluster
Quando estiver tudo pronto para criar clusters para usar com o Anthos Service Mesh, crie e registre-os em uma única etapa com a Google Cloud CLI para usar a configuração padrão. Exemplo:
gcloud container clusters create-auto CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --location=LOCATION
Execute este comando para receber o número do seu projeto da frota:
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
A sinalização
--location
é a zona ou região do Compute (comous-central1-a
ouus-central1
) do cluster.Se o projeto do cluster for diferente do projeto host da frota, será necessário permitir as contas de serviço do Anthos Service Mesh no projeto da frota para acessar o projeto do cluster e ativar as APIs necessárias no projeto do cluster. É necessário fazer isso apenas uma vez para cada projeto de cluster.
Conceda às contas de serviço no projeto da frota permissão para acessar o projeto do cluster:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Ative a API da malha no projeto do cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
Substitua CLUSTER_PROJECT_ID pelo identificador exclusivo do projeto do cluster. Se você criou o cluster no mesmo projeto da frota, CLUSTER_PROJECT_ID será igual ao FLEET_PROJECT_ID.
Prossiga para Verificar se o plano de controle foi provisionado.
Configurar por cluster
Siga as etapas abaixo para configurar o Managed Service Mesh para cada cluster na sua malha.
Ativar o recurso de frota do Anthos Service Mesh
Ative o Anthos Service Mesh no projeto da frota. Observe que, se você planeja registrar vários clusters, a ativação do Anthos Service Mesh acontece no nível da frota. Assim, você só precisa executar esse comando uma vez.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
Registrar clusters em uma frota
Registrar um cluster do GKE com a Identidade da carga de trabalho da frota A sinalização
--location
é a zona ou região do Compute (comous-central1-a
ouus-central1
) do cluster.gcloud container clusters update CLUSTER_NAME \ --location CLUSTER_LOCATION \ --fleet-project FLEET_PROJECT_ID
Verifique se o cluster está registrado:
gcloud container fleet memberships list --project FLEET_PROJECT_ID
Exemplo de saída:
NAME EXTERNAL_ID LOCATION cluster-1 1d8e255d-2b55-4df9-8793-0435461a2cbc us-central1
Anote o MEMBERSHIP_NAME, ele será necessário quando você ativar o gerenciamento automático.
Se o projeto do cluster for diferente do projeto host da frota, será necessário permitir as contas de serviço do Anthos Service Mesh no projeto da frota para acessar o projeto do cluster e ativar as APIs necessárias no projeto do cluster. É necessário fazer isso apenas uma vez para cada projeto de cluster.
Se você já usou o
asmcli
para configurar o Anthos Service Mesh gerenciado para essa combinação de projetos de cluster e de frota, essas alterações já foram aplicadas e não é necessário executar o comando a seguir.Conceda às contas de serviço no projeto da frota permissão para acessar o projeto do cluster:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Ative a API da malha no projeto do cluster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
Ativar gerenciamento automático
Execute o comando a seguir para ativar o gerenciamento automático:
gcloud container fleet mesh update \
--management automatic \
--memberships MEMBERSHIP_NAME \
--project FLEET_PROJECT_ID \
--location MEMBERSHIP_LOCATION
onde:
- MEMBERSHIP_NAME é o nome da assinatura listado quando você verificou que o cluster foi registrado na frota.
MEMBERSHIP_LOCATION é o local da assinatura (uma região ou
global
).Se você criou a assinatura recentemente usando o comando neste guia, ela precisa ser a região do cluster. Se você tiver um cluster zonal, use a região correspondente à zona do cluster. Por exemplo, se você tiver um cluster zonal em
us-central1-c
, use o valorus-central1
.Esse valor pode ser
global
se você se registrou antes de maio de 2023 ou se especificou o localglobal
ao registrar a assinatura. É possível verificar o local da sua assinatura comgcloud container fleet memberships list --project FLEET_PROJECT_ID
.
Verificar se o plano de controle foi provisionado
Após alguns minutos, verifique se o status no plano de controle é ACTIVE
:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
A saída é semelhante a:
...
membershipSpecs:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
mesh:
management: MANAGEMENT_AUTOMATIC
membershipStates:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
servicemesh:
controlPlaneManagement:
details:
- code: REVISION_READY
details: 'Ready: asm-managed'
state: ACTIVE
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Anote o rótulo de revisão no campo details
. Por exemplo,
asm-managed
na saída fornecida. Se você estiver usando rótulos de revisão, defina-o antes de
Implantar aplicativos. Se você está usando marcadores de injeção padrão, não é necessário defini-los.
Configure kubectl
para apontar para o cluster.
As seções a seguir envolvem a execução de comandos kubectl
em cada um dos
clusters. Antes de continuar nas seções a seguir, execute o
comando a seguir para cada um dos clusters e configure o kubectl
para apontar para
o cluster.
gcloud container clusters get-credentials CLUSTER_NAME \
--location CLUSTER_LOCATION \
--project CLUSTER_PROJECT_ID
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 ou de saída, veja Implantar gateways. Para ativar outros recursos opcionais, consulte Como ativar recursos opcionais no Anthos Service Mesh gerenciado.
Plano de dados gerenciado
Se você usa o Anthos Service Mesh gerenciado, o Google gerencia totalmente os upgrades dos proxies, a menos que você o desative no nível de namespace, carga de trabalho ou revisão.
Com o plano de dados gerenciado, os proxies sidecar e os gateways injetados são atualizados automaticamente em conjunto com o plano de controle gerenciado reiniciando cargas de trabalho para injetar novas versões do proxy novamente. Isso normalmente é concluído de uma a duas semanas após o upgrade do plano de controle gerenciado.
Se desativado, o gerenciamento de proxy é determinado pelo ciclo de vida natural dos pods no cluster e precisa ser acionado manualmente pelo usuário para controlar a taxa de atualização.
O plano de dados gerenciado faz upgrade dos proxies removendo os pods que estão executando versões anteriores do proxy. As remoções são feitas gradualmente, honrando o orçamento de interrupção do pod e controlando a taxa de mudança.
O plano de dados gerenciado não gerencia o seguinte:
- Pods não injetados
- Pods injetados manualmente
- Jobs
- StatefulSets
- DaemonSets
Desativar o plano de dados gerenciado (opcional)
Se você estiver provisionando o Anthos Service Mesh gerenciado em um novo cluster, poderá desativar completamente o plano de dados gerenciado ou para namespaces ou pods individuais. O plano de dados gerenciado continuará desativado para os clusters atuais em que foi desativado por padrão ou manualmente.
Para desativar o plano de dados gerenciado no nível do cluster e voltar a gerenciar os proxies sidecar, altere a anotação:
kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Para desativar o plano de dados gerenciado de um namespace:
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Para desativar o plano de dados gerenciado de um pod:
kubectl annotate --overwrite pod POD_NAME \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Ativar notificações de manutenção
É possível solicitar uma notificação sobre a futura manutenção do plano de dados gerenciados até uma semana antes do horário de manutenção. As notificações de manutenção não são enviadas por padrão. Você também precisa configurar uma janela de manutenção do GKE antes de receber notificações. Quando ativadas, as notificações são enviadas pelo menos dois dias antes da operação de upgrade.
Para ativar as notificações de manutenção do plano de dados gerenciado:
Acesse a página Comunicação.
Acesse a página Comunicação.
Na linha Anthos Service Mesh Upgrade, na coluna E-mail, selecione o botão de opção para ativar as notificações de manutenção.
Cada usuário que quer receber notificações precisa aceitar separadamente. Se você quiser definir um filtro de e-mail para essas notificações, a linha de assunto será:
Upcoming upgrade for your Anthos Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"
.
O exemplo a seguir mostra uma notificação típica de manutenção do plano de dados gerenciados:
Assunto: Futuro upgrade para o cluster do ASM "
<location/cluster-name>
"Olá, usuário do Anthos Service Mesh,
O upgrade dos componentes do Anthos Service Mesh no seu cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) está programado para upgrade em ${scheduled_date_human_readable} at ${scheduled_time_human_readable}.
É possível conferir as notas da versão (https://cloud.google.com/service-mesh/docs/release-notes) para saber mais sobre a nova atualização.
Caso essa manutenção seja reprogramada, você receberá outro e-mail com informações.
Até mais,
Equipe do Anthos Service Mesh
(c) 2022 Google LLC, 1600, Amphitheater Parkway, Mountain View, CA 94043 Enviamos este aviso para informar sobre mudanças importantes no Google Cloud Platform ou na sua conta. Para desativar as notificações sobre janelas de manutenção, altere suas preferências de usuário: https://console.cloud.google.com/user-preferences/communication?project=
Configurar a descoberta de endpoint (somente para instalações de vários clusters)
Antes de prosseguir, você precisa ter configurado o Anthos Service Mesh gerenciado em cada cluster, conforme descrito nas etapas anteriores. Não há necessidade de indicar que um cluster é primário, pois esse é o comportamento padrão.
Além disso, verifique se você
fez o download de asmcli
(somente se quiser verificar sua configuração com o aplicativo de amostra) e
defina as variáveis do projeto e do cluster.
Clusters públicos
Configurar a descoberta de endpoints entre clusters públicos
Ativar o Anthos Service Mesh gerenciado com a API Fleet ativará a descoberta de endpoints para este cluster. No entanto, é necessário abrir portas de firewall. Para desativar a descoberta de endpoints de um ou mais clusters, consulte as instruções para desativá-la em Descoberta de endpoints entre clusters públicos com a API declarativa.
Clusters particulares
Configurar a descoberta de endpoints entre clusters particulares
Ativar o Anthos Service Mesh gerenciado com a API Fleet ativará a descoberta de endpoints para este cluster. No entanto, é necessário abrir portas de firewall. Para desativar a descoberta de endpoints de um ou mais clusters, consulte as instruções para desativá-la em Descoberta de endpoints entre clusters particulares com a API declarativa.
Para um aplicativo de exemplo com dois clusters, veja Exemplo de serviço HelloWorld.
Implanta aplicativos
Se você tiver mais de um cluster na frota usando o Anthos Service Mesh gerenciado, verifique se a descoberta de endpoints ou as portas de firewall estão configuradas conforme o esperado antes de prosseguir e implantar aplicativos.Para implantar aplicativos, use o rótulo correspondente ao canal que você
configurou durante a instalação ou istio-injection=enabled
se estiver usando
rótulos de injeção padrão.
Rótulo de injeção padrão
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Rótulo de revisão
Antes de implantar aplicativos, remova os rótulos istio-injection
anteriores
dos namespaces e defina o rótulo istio.io/rev=REVISION_LABEL
.
Esse é o rótulo de revisão que você identificou quando
verificou o plano de controle.
Para alterá-lo para um identificador de revisão específico, clique em REVISION_LABEL
e substitua-o pelo identificador aplicável: asm-managed-rapid
para Rápido, asm-managed
para Regular ou asm-managed-stable
para Estável.
O rótulo de revisão corresponde a um canal de lançamento:
Rótulo de revisão | Channel |
---|---|
asm-managed |
Normal |
asm-managed-rapid |
Rápido |
asm-managed-stable |
Canal Stable |
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Você já configurou o Anthos Service Mesh gerenciado. Se você tiver cargas de trabalho em namespaces rotulados, reinicie-os para que possam ser injetados os proxies.
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.
Personalizar injeção (opcional)
A configuração por pod está disponível para substituir essas opções em pods individuais.
Para fazer isso, adicione um contêiner istio-proxy
ao seu pod. A injeção
de sidecar vai tratar qualquer configuração definida aqui como uma substituição do
modelo de injeção padrão.
Por exemplo, a configuração a seguir personaliza várias configurações, incluindo a redução das solicitações de CPU, adição de uma montagem de volume e adição de um hook preStop
:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: hello
image: alpine
- name: istio-proxy
image: auto
resources:
requests:
cpu: "200m"
memory: "256Mi"
limites:
cpu: "200m"
memory: "256Mi"
volumeMounts:
- mountPath: /etc/certs
name: certs
lifecycle:
preStop:
exec:
command: ["sleep", "10"]
volumes:
- name: certs
secret:
secretName: istio-certs
Em geral, qualquer campo em um pod pode ser definido. No entanto, é preciso ter cuidado com alguns campos:
- O Kubernetes exige que o campo
image
seja definido antes da execução da injeção. Embora seja possível definir uma imagem específica para substituir a padrão, recomendamos definir aimage
comoauto
, o que fará com que o injetor do sidecar selecione a imagem automaticamente. - Alguns campos em
containers
dependem de configurações relacionadas. Por exemplo, a solicitação da CPU precisa ser menor que o limite da CPU. Se os dois campos não estiverem configurados corretamente, o pod pode não ser iniciado. - O Kubernetes permite definir
requests
elimits
para recursos noPodSpec
. O GKE Autopilot só considerarequests
. Para mais informações, consulte Como definir limites de recursos no Autopilot.
Além disso, alguns campos podem ser configurados por anotações no pod, mas é recomendável usar a abordagem acima para personalizar as configurações. É preciso ter cuidado com algumas anotações:
- Para o GKE Standard, se
sidecar.istio.io/proxyCPU
estiver definido, defina explicitamentesidecar.istio.io/proxyCPULimit
. Caso contrário, o limite de CPU do arquivo secundário será definido como ilimitado. - Para o GKE Standard, se
sidecar.istio.io/proxyMemory
estiver definido, defina explicitamentesidecar.istio.io/proxyMemoryLimit
. Caso contrário, o limite de memória do arquivo secundário será definido como ilimitado. - No GKE Autopilot, configurar o recurso
requests
elimits
usando anotações pode superprovisionar recursos. Use a abordagem de modelo de imagem para evitar. Consulte Exemplos de modificação de recursos no Autopilot.
Por exemplo, consulte a configuração da anotação de recursos abaixo:
spec:
template:
metadata:
annotations:
sidecar.istio.io/proxyCPU: "200m"
sidecar.istio.io/proxyCPULimit: "200m"
sidecar.istio.io/proxyMemory: "256Mi"
sidecar.istio.io/proxyMemoryLimit: "256Mi"
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-REVISION_LABEL"
- Agrupar por: marcador
revision
eproxy_version
marcador - 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
Para migrar aplicativos do Anthos Service Mesh no cluster para o Anthos Service Mesh gerenciado, execute as seguintes etapas:
Substitua o rótulo de namespace atual. As etapas necessárias dependem do uso de rótulos de injeção padrão (por exemplo,
istio-injection enabled
) ou do identificador de revisãoRótulo de injeção padrão
Execute o seguinte comando para mover a tag padrão para a revisão gerenciada:
istioctl tag set default --revision REVISION_LABEL
Execute o seguinte comando para rotular o namespace usando
istio-injection=enabled
, se ele ainda não tiver sido feito:kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \ --overwrite
Rótulo de revisão
Se você usou o rótulo
istio.io/rev=REVISION_LABEL
, execute o seguinte comando:kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \ --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.
Se o aplicativo funcionar como esperado, é possível remover o
cluster istiod
interno depois de alternar todos os namespaces para o plano de controle gerenciado
pelo cliente ou mantê-los como backup. istiod
reduzirá automaticamente
para usar 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
Desinstalar o Anthos Service Mesh.
O plano de controle gerenciado reduz a escala a zero automaticamente quando nenhum namespace está usando esse recurso. Para etapas detalhadas, consulte Desinstalar o Anthos Service Mesh.
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 como ativar recursos opcionais do Anthos Service Mesh gerenciado, como:
- Como configurar a segurança de transporte para proteger sua malha.