Glossário

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, namespace e service account. Ela tem um formato de identidade SPIFFE de spiffe://<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

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

Gateway de entrada

Um gateway de entrada representa um balanceador de carga para lidar com o tráfego de entrada que sai da malha. Use os recursos do Gateway do Istio 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.

istiod

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

IstioOperator

Um 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).
CA da malha: O nome da autoridade de certificação gerenciada pelo Google que administra certificados mTLS. A CA da malha é instalada por padrão quando você instala o Anthos Service Mesh.
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 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. Ao instalar ou fazer 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 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.

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