Environs são um conceito do Google Cloud para organizar logicamente clusters e outros recursos. Eles permitem que você use e gerencie recursos de vários clusters e aplique políticas consistentes nos seus sistemas. Os Environs formam uma parte essencial do funcionamento da funcionalidade corporativa de vários clusters no Anthos. Elas também são usadas em alguns recursos do Google Kubernetes Engine (GKE).
Neste guia, você encontrará a descrição de um ambiente: o que significa por um ambiente, onde os ambientes são usados nos nossos componentes e como configurar seus sistemas para aproveitar os recursos no nível do ambiente. Também fornecemos alguns exemplos que ilustram como os ambientes podem ajudar a simplificar o gerenciamento do cluster e do sistema, além das práticas recomendadas a serem seguidas ao criar e operar sistemas de vários clusters com ambientes.
Este guia foi desenvolvido para leitores técnicos, incluindo arquitetos do sistema, operadores de plataforma e operadores de serviço, que querem aproveitar vários clusters e uma infraestrutura relacionada. Esses conceitos são úteis onde sua organização executa vários clusters, seja no Google Cloud, em vários provedores de nuvem ou no local.
Você precisa estar familiarizado com os conceitos básicos do Kubernetes, como clusters. Caso contrário, consulte Noções básicas do Kubernetes, a documentação do GKE e Como preparar um aplicativo para o serviço do Anthos Malha
Se você quiser saber mais sobre o Anthos e os componentes que usam ambientes, consulte nossa visão geral técnica e o tutorial Explorar o Anthos. No entanto, você não precisa estar familiarizado com o Anthos para seguir este guia.
Introdução
Normalmente, conforme as organizações unem as tecnologias nativas da nuvem, como contêineres, orquestração de contêineres e malhas de serviço, elas alcançam um ponto em que a execução de um único cluster não é mais suficiente. Há vários motivos pelos quais as organizações optam por implantar vários clusters para atingir os objetivos técnicos e comerciais. por exemplo, separar a produção de ambientes que não sejam de produção ou separar serviços entre camadas, localidades ou equipes. Saiba mais sobre os benefícios e as desvantagens envolvidas em abordagens de vários clusters em casos de uso de vários clusters.
number medida que o número de clusters aumenta, o gerenciamento e a governança sobre esses clusters e os recursos dentro deles se tornam cada vez mais difíceis. Muitas vezes, as organizações contam para criar ferramentas e políticas operacionais personalizadas para alcançar o nível de controle exigido.
O Google Cloud fornece o conceito de ambiente para ajudar os administradores a gerenciar vários clusters. Um ambiente oferece um modo de agrupar e normalizar clusters de maneira lógica, facilitando a administração da infraestrutura. Os Environs podem ser usados no contexto do Anthos e do GKE; É possível ver uma lista dos componentes do Anthos e do GKE que podem aproveitar os ambientes na seção Componentes compatíveis com o ambiente posteriormente neste documento.
A adoção de ambientes ajuda a organização a gerenciar níveis de clusters individuais para grupos inteiros de clusters. Além disso, a normalização que os ambientes exigem pode ajudar suas equipes a adotar práticas recomendadas semelhantes às usadas no Google. Para fins de comparação, assim como o recurso Organização é o nó raiz da hierarquia de recursos do Google Cloud e é usado para políticas e controle sobre os recursos agrupados sob ela, o ambiente forma a raiz para o gerenciamento de vários clusters.
Terminologia
Veja a seguir alguns termos importantes que usamos ao falar sobre ambientes.
Recursos com reconhecimento de energia
Os recursos com reconhecimento de humanos são recursos do projeto do Google Cloud que podem ser agrupados e gerenciados de forma lógica como ambientes. Atualmente, somente clusters do Kubernetes podem ser membros de ambiente, apesar de a suspensão de instâncias de máquina virtual (VM, na sigla em inglês) e, possivelmente, de outros recursos a possibilidade de ingressar a tipos de ambiente no futuro. O Google Cloud fornece um serviço do Connect para registrar recursos como membros do ambiente.
Projeto de host do Environ
A implementação de ambientes, como muitos outros recursos do Google Cloud, é fornecida em um projeto do Google Cloud, que chamamos de projeto host do ambiente. Um determinado projeto do Cloud pode ter apenas um único ambiente (ou nenhum ambiente) associado a ele. Essa restrição reforça o uso de projetos do Cloud para fornecer isolamento mais forte entre recursos que não são regidos ou consumidos em conjunto.
Componentes compatíveis com Environ
Os seguintes componentes do Anthos e do GKE aproveitam os conceitos de ambiente, como namespace e identidade de identidade, para oferecer uma maneira simplificada de trabalhar com clusters e serviços. Para conhecer os requisitos ou limitações atuais para o uso de ambientes com cada componente, consulte os requisitos de componente.
Pools de identidade da carga de trabalho (clusters do Anthos e GKE)
Um Environ oferece um pool de identidades da carga de trabalho comum que pode ser usado para autenticar e autorizar cargas de trabalho de maneira uniforme dentro de uma malha de serviço e para serviços externos.Anthos Service Mesh (Anthos)
O Anthos Service Mesh é um pacote de ferramentas que ajuda a monitorar e gerenciar uma malha de serviço confiável no Google Na nuvem ou no local. É possível formar uma malha de serviço nos recursos (como clusters e VMs) que fazem parte do mesmo ambiente.Anthos Config Management (Anthos) e Config Sync (GKE)
O Anthos Config Management permite implantar e monitorar políticas declarativas e alterações de configuração no seu sistema armazenadas em um Git central usando os conceitos principais do Kubernetes, como namespaces, rótulos e anotações. Com o Anthos Config Management, e o respectivo produto Config Sync para clusters que não são do Anthos, a política e a configuração são definidas em todo o ambiente, mas aplicadas e aplicadas localmente em cada um dos recursos membros.Entrada com vários clusters (Anthos)
A Entrada de vários clusters usa o ambiente para definir o conjunto de clusters e endpoints de serviço em que o tráfego pode ser submetido ao balanceamento de carga, permitindo latência e serviços de alta disponibilidade.
Como agrupar a infraestrutura
O primeiro conceito importante de ambientes é oagrupamento ou seja, escolher quais partesrelacionadas Recursos com reconhecimento de ambiente deve ser parte de um ambiente. A decisão sobre o que agrupar deve exigir respostas para as seguintes perguntas:
- Os recursos estão relacionados?
- Recursos com grandes quantidades de comunicação entre serviços são mais beneficiados com o gerenciamento conjunto em um ambiente.
- Os recursos no mesmo ambiente de implantação (por exemplo, o ambiente de produção) devem ser gerenciados juntos em um ambiente.
- Quem administra os recursos?
- Ter um controle unificado (ou pelo menos mutuamente confiável) sobre os recursos é essencial para garantir a integridade do ambiente.
Para ilustrar esse ponto, considere uma organização que tenha várias linhas de negócios (LOBs). Nesse caso, os serviços raramente se comunicam entre os limites LOB, os serviços em diferentes LOBs são gerenciados de maneira diferente (por exemplo, os ciclos de upgrade diferem entre os LOBs) e podem até mesmo ter um conjunto diferente de administradores para cada um. LOB Nesse caso, talvez faça sentido ter ambientes por LOB. Cada LOB também adota vários ambientes para separar os serviços de produção e não produção.
other medida que outros conceitos de ambiente são explorados nas seções a seguir, você pode encontrar outros motivos para criar vários ambientes ao considerar suas necessidades organizacionais específicas.
Semelhança
Um conceito importante no ambiente é o de semelhança. Isso significa que alguns objetos do Kubernetes, como clusters com o mesmo nome em contextos diferentes, são tratados como a mesma coisa. Essa normalização é feita para tornar a administração de recursos de ambiente mais terríveis. Ela traz algumas orientações úteis sobre como configurar namespaces, serviços e identidades. Porém, ela também segue o que descobrimos que a maioria das organizações já implementa.
Semelhança de namespace
O exemplo fundamental da mesma igualdade em um ambiente é a mesma do namespace. Os namespaces com o mesmo nome em clusters diferentes são considerados os mesmos de muitos componentes. Outra maneira de pensar sobre essa propriedade é que um namespace é logicamente definido em um ambiente inteiro, mesmo que a instanciação do namespace exista apenas em um subconjunto dos recursos do ambiente.
Considere o seguinte exemplo de namespace backend. O namespace é instanciado
apenas nos clusters A e B, mas implicitamente reservado no Cluster C.
Ele permite que o serviço backend também seja programado no cluster C, se necessário.
Isso significa que os namespaces são alocados para todo o ambiente e não por
cluster. Assim, a igualdade de namespace requer propriedade consistente de namespace
em todo o ambiente.
Semelhança de serviços
O Anthos Service Mesh e o Ingress de vários clusters usam o conceito de igualdade de serviços dentro de um namespace. Assim como a semelhança de namespace, isso significa que serviços com o mesmo namespace e nome de serviço são considerados o mesmo serviço.
Os endpoints do serviço podem ser mesclados na malha, no caso do Anthos Service Mesh. Com a Entrada de vários clusters, um recurso MultiClusterService (MCS) torna o endpoint integrado mais explícito. No entanto, recomendamos práticas semelhantes com relação à nomenclatura. Por isso, é importante garantir que os nomes de serviço com nomes idênticos dentro do mesmo namespace sejam, na verdade, os mesmos.
No exemplo a seguir, o tráfego da Internet tem a carga balanceada em um serviço
com nome igual no namespace frontend presente nos clusters B e C. Da mesma forma,
usando as propriedades da malha de serviço no ambiente, o serviço frontend pode
acessar um serviço com o mesmo nome no namespace auth presente nos clusters A e C.
Semelhança de identidade ao acessar recursos externos
Os serviços dentro de um ambiente podem usar uma identidade comum quando vão para acessar recursos externos, como serviços do Google Cloud, armazenamentos de objetos e assim por diante. Essa identidade comum possibilita que os serviços dentro de um ambiente acessem um recurso externo em vez de cluster a cluster.
Para entender melhor esse ponto, considere o exemplo a seguir. Os clusters A, B
e C estão inscritos em uma identidade comum no ambiente. Quando os serviços no namespace
backend acessam recursos do Google Cloud, as identidades deles são
mapeadas para uma conta de serviço comum do Google Cloud chamada back. A
conta de serviço do Google Cloud back pode ser autorizada em qualquer número
de serviços gerenciados, do Cloud Storage ao Cloud SQL. À medida que novos recursos de ambiente,
como clusters, são adicionados ao namespace backend, eles herdam
automaticamente as propriedades de semelhança de identidade da carga de trabalho.
Devido à igualdade de identidade, é importante que todos os recursos em um ambiente
sejam confiáveis e bem controlados. Se você revisitar o exemplo anterior, se o Cluster C
pertence a uma equipe separada e não confiável, ele também pode criar um namespace backend
e acessar serviços gerenciados como se fossembackend no Cluster A
ou B.
Semelhança de identidade dentro de um ambiente
Dentro do ambiente, a mesma identidade é usada de forma semelhante à semelhança de identidade externa que discutimos anteriormente. Assim como os serviços de ambiente são autorizados uma vez para um serviço externo, eles também podem ser autorizados internamente.
No exemplo a seguir, fornecemos acesso de frontend a backend. Com
ambientes, não é necessário especificar que frontend nos clusters B e C possam
acessar backend nos clusters A e B. Em vez disso, especificamos que apenas frontend
no ambiente pode acessar backend no ambiente. Além de deixar a autorização mais simples,
ela também torna os limites de recursos mais flexíveis. agora
as cargas de trabalho podem ser facilmente movidas do cluster para o cluster sem afetar o modo como
são autorizadas. Assim como na igualdade de identidade de carga de trabalho,
a governança sobre os recursos do ambiente é fundamental para garantir a integridade da comunicação de serviço
a serviço.
Exclusividade
Os recursos com reconhecimento de vagas só podem ser membros de um único ambiente em qualquer momento, uma restrição aplicada por ferramentas e componentes do Google Cloud. Essa restrição garante que haja apenas uma fonte de verdade que regula um cluster. Sem exclusividade, mesmo os componentes mais simples se tornariam complexos de usar, exigindo que sua organização pensasse e configurariacomo seria feita a interação de vários componentes de diversos ambientes.
Alta confiança
A igualdade de serviço, a mesma identidade de carga de trabalho e a semelhança de identidade de malha são criadas com base em um princípio de alta confiança entre os membros de um ambiente. Essa confiança possibilita um nível superior no gerenciamento desses recursos para o ambiente, em vez de gerenciar recurso por recurso (ou seja, cluster por cluster para recursos do Kubernetes) e, por fim, possibilita limite de cluster menos importante.
Em outras palavras, os clusters oferecem proteção contra preocupações em raios, disponibilidade (do plano de controle e da infraestrutura subjacente), vizinhos com ruídos e assim por diante. No entanto, eles não são um forte limite de isolamento para políticas e governança porque os administradores de qualquer membro em um ambiente podem afetar as operações dos serviços em outros membros.
Por esse motivo, recomendamos que os recursos não confiáveis pelo administrador do ambiente sejam colocados nos próprios ambientes para mantê-los isolados. Em seguida, conforme necessário, serviços individuais podem ser autorizados no limite do ambiente.
A seguir
Quer pensar na aplicação desses conceitos nos seus próprios sistemas? Consulte nossos requisitos e práticas recomendadas para o ambiente.