Glossário

Nesta página, você encontra definições resumidas e links sobre termos usados na documentação do Anthos Service Mesh.

C

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 (Visualização): é 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ê.
Plano de controle no cluster: essa é uma distribuição compatível com o Google do istiod que você instala no cluster. Ao instalar o Anthos Service Mesh com istiod, você é responsável por fazer o upgrade e configurar a segurança e o 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.

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.

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

istiod

O Istiod é 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.

IstioOperator

Um recurso personalizado usado para configurar o plano de controle. Para mais informações, consulte IstioOperator nos documentos do Istio.

milhões

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.

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 substituir a configuração padrão do plano de controle e ativar os recursos opcionais compatíveis em um arquivo YAML que você transmite para istioctl install ou para o script install_asm. É 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 e ative 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 a istiod para identificar a versão. Para ativar a injeção automática de arquivo secundário, adicione o rótulo de revisão aos namespaces e reinicie os pods. Use o rótulo de revisão para associar os pods em um namespace a uma determinada revisão de istiod. Assim, é possível fazer upgrade com segurança para um novo plano de controle e reverter para a revisão original em caso de problemas.

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 arquivos secundários 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 substring mytrustdomain.com especifica que a carga de trabalho é de um domínio confiável chamado mytrustdomain.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, na forma de project-id.svc.id.goog ou project-id.hub.id.goog.

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