Nesta página, você encontra definições resumidas e links sobre termos usados na documentação do Anthos Service Mesh.
A
- Identidade da carga de trabalho do Anthos
- uma tuple
de
trust domain,namespaceeservice account. Ela tem um formato de identidade SPIFFE despiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount>nos certificados x509 da carga de trabalho do Anthos. Para outros tipos de credenciais (por exemplo, tokens IDC), o formato pode variar.
C
- migração de cluster canário
- A migração de cluster canário é uma estratégia de migração comum usada para migrar do Istio para o Anthos Service Mesh, em que você ativa o Anthos Service Mesh em um novo cluster separado. A estratégia de migração do cluster canário é abordada no tutorial, Migrar o Istio 1.11 ou mais recente para o Anthos Service Mesh gerenciado. A migração do cluster canário também pode ser usada ao migrar do Anthos Service Mesh no cluster para o Anthos Service Mesh gerenciado. A outra estratégia comum é a migração do plano de controle canário.
- migração do plano de controle canário
- A migração do plano de controle canário é uma estratégia de migração comum usada para migrar do Istio para o Anthos Service Mesh, em que o Anthos Service Mesh é ativado no cluster atual instalado pelo Istio. A migração consiste em rotular novamente os namespaces para que o plano de dados use o Anthos Service Mesh. A migração do cluster canário também pode ser usada ao migrar do Anthos Service Mesh no cluster para o Anthos Service Mesh gerenciado. A outra estratégia comum é a migração do cluster canário.
- upgrade canário
- Consulte o upgrade baseado em revisão.
- Canonical Service
- Um rótulo aplicado a cargas de trabalho no Anthos Service Mesh que permite agrupar uma ou mais cargas de trabalho como um serviço lógico na malha de serviço. Uma carga de trabalho pertence exatamente a um serviço canônico e pode pertencer a vários serviços do Kubernetes. Um serviço canônico é identificado por um nome e um namespace e pode ser dividido em uma ou mais revisões canônicas.
- plano de controle
Um plano de controle é um conjunto de serviços do sistema que configura a malha ou um subconjunto da malha para gerenciar a comunicação entre as instâncias da carga de trabalho. O Anthos Service Mesh 1.9 e posteriores fornece dois planos de controle:
Plano de controle gerenciado pelo Google: é um serviço do Google Cloud totalmente gerenciado que você só precisa configurar, enquanto o Google lida com a confiabilidade , upgrades, escalonamento e segurança para você. O Anthos Service Mesh gerenciado consiste no plano de controle gerenciado pelo Google e no plano de dados opcional gerenciado pelo Google, que está em Visualização.
Plano de controle no cluster: essa é uma distribuição compatível com o Google do
istiodque você instala no cluster. Ao instalar o Anthos Service Mesh com oistiod, você é responsável pelo upgrade e pela configuração da segurança e do escalonamento.
Embora o plano de controle distribua a configuração para os proxies sidecar, ele não participa diretamente do processamento do tráfego das cargas de trabalho na malha.
D
- plano de dados
- O plano de dados é a parte da malha que controla diretamente a comunicação entre instâncias de carga de trabalho. O plano de dados do Anthos Service Mesh usa proxies implantados como arquivos secundários para mediar e controlar todo o tráfego TCP que os serviços da malha enviam e recebem. O Managed Mesh Service Mesh oferece um plano de dados gerenciado pelo Google, que está em Visualização.
E
- Gateway de saída
- Um gateway de saída é um proxy Envoy que permite configurar um nó de saída dedicado para o tráfego que sai da malha. Você usa o recurso personalizado Gateway para configurar o proxy. Um gateway de saída permite limitar quais serviços podem ou precisam acessar redes externas. Consulte Instalar e fazer upgrade de gateways para mais informações.
F
- frota
- Uma frota (anteriormente conhecida como ambiente) permite organizar clusters para facilitar o gerenciamento de vários deles. Registrar os clusters em uma frota simplifica o gerenciamento de uma malha de vários clusters ao introduzir o conceito de "semelhança" para identidades, namespaces e serviços. Se você tiver clusters em projetos diferentes, será necessário registrar os clusters com o projeto host da frota em vez de com o projeto em que o cluster foi criado. Para saber mais sobre as frotas, consulte Introdução às frotas.
H
- manifestos hidratados
- Um manifesto pronto para implantação no destino. Para hidratar um manifesto, normalmente você usa uma ferramenta como Helm, Kustomize ou
kptpara definir valores para as variáveis no manifesto.
I
- identity
A identidade é um conceito fundamental de infraestrutura de segurança. O modelo de identidade do Anthos Service Mesh é baseado em uma identidade de carga de trabalho de primeira classe. No início da comunicação de serviço a serviço, as duas partes trocam credenciais com informações de identidade para fins de autenticação mútua.
Os clientes verificam a identidade do servidor com as informações de nomenclatura seguras para determinar se o servidor está autorizado a executar o serviço.
Os servidores verificam a identidade do cliente para determinar quais informações ele pode acessar. Os servidores decidem se o acesso será permitido com base nas políticas de autorização configuradas.
Usando a identidade, os servidores podem auditar a hora em que as informações foram acessadas e quais informações foram acessadas por um cliente específico. Eles também podem cobrar os clientes com base nos serviços usados e rejeitar qualquer cliente que não pague a fatura de acesso aos serviços.
O modelo de identidade do Anthos Service Mesh é flexível e granular o suficiente para representar um usuário humano, um serviço individual ou um grupo de serviços. Em plataformas sem identidade de serviço de primeira classe, o Anthos Service Mesh pode usar outras identidades que podem agrupar instâncias de serviço, como nomes de serviço.
O Anthos Service Mesh é compatível com as seguintes identidades de serviço em diferentes plataformas:
Kubernetes: conta de serviço do Kubernetes
Google Kubernetes Engine: conta de serviço do Google Cloud
Google Cloud: conta de serviço do Google Cloud
- Gateway de entrada
Um gateway de entrada é um proxy Envoy que funciona como um balanceador de carga para processar o tráfego de entrada vindo de fora da malha. Use o recurso personalizado do Gateway para configurar o balanceador de carga e criar serviços virtuais e políticas de autenticação para controlar como o tráfego de entrada é protegido e roteado para suas cargas de trabalho. Consulte Instalar e fazer upgrade de gateways para mais informações.
- Injeção
Injeção, ou injeção automática, refere-se ao uso de mutadores de mutação para modificar as especificações do pod no momento da criação. Use a injeção para adicionar a configuração de arquivo secundário do proxy Envoy para seus serviços de malha ou para configurar o proxy Envoy de gateways
- upgrade no local
Um upgrade no local substitui o plano de controle atual por uma nova revisão. Como prática recomendada, recomendamos upgrades baseados em revisão.
istiodO
istiod(o "d" significa "daemon") é o binário monolítico consolidado que fornece serviços de plano de controle. Antes do Anthos Service Mesh 1.5, os serviços do plano de controle eram fornecidos por componentes separados chamados Pilot, Citadel, Mixer e Galley.IstioOperatorUm recurso personalizado usado para configurar o plano de controle no cluster. Para mais informações, consulte Como ativar recursos opcionais.
M
- Grupo gerenciado de instâncias (MIG)
- Permite operar aplicativos em várias VMs idênticas, começando com o tamanho mínimo de MIG de uma VM. É possível tornar as cargas de trabalho escalonáveis e altamente disponíveis aproveitando serviços de MIGs automatizados, como escalonamento automático, recuperação automática, implantação regional (várias zonas) e atualização automática. Para mais informações, consulte Grupos gerenciados de instâncias (MIGs, na sigla em inglês).
- Manifesto
Um objeto de configuração do Kubernetes usado para criar, modificar e excluir recursos do Kubernetes, como pods, implantações, serviços ou entradas. Na documentação do Anthos Service Mesh, o manifesto usado para configurar o plano de controle é chamado de arquivo de sobreposição.
Os manifestos existem em um dos dois estados: renderizado (também chamado de hidratado) ou não renderizado. Um manifesto não renderizado não está pronto para implantação em um destino. O processo de renderização, que inclui o preenchimento de valores específicos no manifesto, geralmente é realizado por ferramentas como Helm, Kustomize e
kpt.- CA da malha
O nome da autoridade de certificação gerenciada pelo Google que administra certificados mTLS. A CA da malha é ativada por padrão quando você instala o Anthos Service Mesh em clusters do GKE no Google Cloud e, como opção, pode ativar a CA da malha ao instalar o Anthos Service Mesh 1.10 ou mais recente no GKE no VMware ou bare metal.
- TLS mútuo
O Anthos Service Mesh usa TLS mútuo (mTLS) para autenticação e criptografia entre serviços na malha. O mTLS possibilita que as cargas de trabalho verifiquem as identidades umas das outras e se conectem entre si. Talvez você esteja familiarizado com o TLS simples por meio do uso dele em HTTPS para permitir que os navegadores confiem em servidores da Web e criptografam os dados que são trocados. Quando o TLS simples é usado, o cliente estabelece que o servidor pode ser confiável ao validar o certificado. mTLS é uma implementação de TLS em que o cliente e o servidor apresentam certificados entre si e verificam as identidades umas das outras.
N
- network
- O Anthos Service Mesh usa uma definição simplificada de rede com base na conectividade geral. Instâncias de carga de trabalho ficam na mesma rede, se puderem se comunicar diretamente, sem um gateway.
O
- arquivo de sobreposição
- Um arquivo YAML com um recurso personalizado
IstioOperator(CR). Você usa arquivos de sobreposição para configurar o plano de controle. É possível modificar a configuração do plano de controle padrão e ativar recursos opcionais compatíveis em um arquivo YAML que você transmite paraistioctl install,install_asmouasmcli install. É possível usar mais camadas, e cada arquivo de sobreposição substitui a configuração nas camadas anteriores. Consulte Como ativar recursos opcionais para o YAML que pode ser usado para ativar recursos não ativados por padrão.
P
- cluster principal
- Um cluster principal é um cluster com um plano de controle. Uma única malha pode ter mais de um cluster principal para alta disponibilidade ou reduzir a latência. Na documentação do Istio 1.7, uma implantação multiprimária é chamada de plano de controle replicado.
R
- cluster remoto
- Um cluster remoto se conecta a um plano de controle residente fora do cluster. Um cluster remoto pode se conectar a um plano de controle em execução em um cluster principal ou a um plano de controle externo.
- revisão
- Uma revisão representa um snapshot no tempo da versão e da configuração de código do aplicativo. Quando você instala ou faz upgrade do Anthos Service Mesh, um rótulo de revisão é adicionado ao plano de controle. Para ativar a injeção automática de arquivo secundário, adicione o rótulo de revisão aos namespaces e reinicie os pods. O rótulo de revisão associa os pods de um namespace a uma revisão de plano de controle específica.
- upgrade baseado em revisão
- As migrações do OSS Istio e os upgrades seguem o processo de upgrade baseado na revisão (chamado de "upgrades canário" na documentação do Istio). Com um upgrade baseado em revisão, a nova revisão do plano de controle é instalada com o plano de controle atual. Depois, transfira algumas das cargas de trabalho para a nova revisão. Isso permite monitorar o efeito do upgrade com uma pequena porcentagem das cargas de trabalho antes de migrar todo o tráfego para a nova revisão.
S
- nomenclatura segura
- As identidades dos servidores são codificadas em certificados, mas os nomes de serviços são
recuperados com o serviço de descoberta ou com o DNS. As informações de nomenclatura segura
mapeiam as identidades do servidor para os nomes de serviço. Um mapeamento da identidade A para
o nome de serviço B significa "A está autorizado a executar o serviço B". O plano de controle
observa o
apiserver, gera os mapeamentos de nomenclatura segura e os distribui com segurança aos proxies sidecar. - malha de serviço
- Uma malha de serviço, ou simplesmente malha, é uma camada de infraestrutura que permite a comunicação gerenciada, observável e segura entre instâncias de carga de trabalho.
- Arquivo secundário
- Um padrão para executar um utilitário ou um auxiliar com uma carga de trabalho. Se você estiver usando o Kubernetes, os sidecars serão executados junto do contêiner da carga de trabalho em um pod. Ao discutir a malha de serviço, a palavra "arquivo secundário" é frequentemente usada para se referir ao proxy.
T
- domínio de confiança
Domínio de confiança corresponde à raiz de confiança de um sistema e faz parte de uma identidade de carga de trabalho.
O Anthos Service Mesh usa um domínio confiável para criar todas as identidades em uma malha. Por exemplo, no ID SPIFFE
spiffe://mytrustdomain.com/ns/default/sa/myname, a substringmytrustdomain.comespecifica que a carga de trabalho é de um domínio confiável chamadomytrustdomain.com.Ao usar a CA da malha, o domínio de confiança é gerado automaticamente pelo Anthos Service Mesh. Ele é baseado no pool de carga de trabalho do cluster.
É possível ter um ou mais domínios de confiança em uma malha de vários clusters, desde que eles tenham a mesma raiz de confiança.
W
- carga de trabalho
- Uma carga de trabalho é um aplicativo, serviço ou outro programa em contêiner, como um job em lote ou daemon em execução em uma plataforma. A plataforma pode ser um cluster do Kubernetes, uma máquina virtual ou outro ambiente, como o Google Distributed Cloud Virtual para Bare Metal. As cargas de trabalho têm nomes, namespaces e IDs exclusivos. No Kubernetes, uma carga de trabalho normalmente corresponde a uma implantação, mas há outros tipos de cargas de trabalho, como um StatefulSet.
- WorkloadEntry
- Permite que você descreva endpoints que não sejam do Kubernetes e que façam parte da malha, além de tratá-los como um pod do Kubernetes. No nosso caso, cada VM é registrada como uma WorkloadEntry na malha. Para mais informações, consulte https://istio.io/latest/blog/2020/workload-entry/
- WorkloadGroup
- Descreve uma coleção de instâncias de carga de trabalho. Consulte WorkloadGroup.
- Pool de identidade de carga de trabalho
- O limite de confiança, também conhecido como domínio de confiança de um Anthos Service Mesh.