Como preparar um ambiente do Google Kubernetes Engine para produção

Neste documento, descrevemos como integrar cargas de trabalho conteinerizadas ao Google Kubernetes Engine (GKE) com mais segurança, confiabilidade e economia. Ela orienta na configuração do acesso administrativo e de rede aos clusters. Neste artigo, pressupomos uma compreensão prática dos recursos e da administração de cluster do Kubernetes, além de familiaridade com os recursos de rede do Google Cloud.

Arquitetura de amostra

O diagrama a seguir mostra um exemplo de uma estrutura flexível e altamente disponível para implantar um cluster do GKE.

Estrutura de projeto, rede e cluster.

Projetos

O Google Cloud cria todos os recursos próprios em uma entidade de projeto.

É possível usar projetos para representar vários ambientes operacionais. Por exemplo, é possível ter os projetos production e staging para equipes de operações e um projeto development para desenvolvedores. É possível aplicar políticas mais granulares e rígidas aos projetos que armazenam os dados e cargas de trabalho mais críticos e confidenciais. Em seguida, é possível aplicar políticas mais permissivas e flexíveis para os desenvolvedores no ambiente development fazerem testes.

Clusters

Um projeto pode conter vários clusters. Se você tiver várias cargas de trabalho para implantar, é possível usar um único cluster compartilhado ou clusters separados para essas cargas de trabalho.

Redes e sub-redes

Dentro de cada projeto, você pode ter uma ou mais redes VPC, que são versões virtuais de redes físicas. Cada rede VPC é um recurso global que contém outros recursos relacionados à rede, como sub-redes, endereços IP externos, regras de firewall, rotas, VPN e o Cloud Router. Em uma rede VPC, é possível usar sub-redes, que são recursos regionais, para isolar e controlar o tráfego recebido ou enviado por cada região entre os clusters do GKE.

Cada projeto inclui uma única rede padrão. É possível criar e configurar uma rede extra para mapear para convenção atual de gerenciamento de endereços IP (IPAM, na sigla em inglês). Aplique, então, as regras de firewall à rede para filtrar o tráfego de entrada e saída dos nós do GKE. Por padrão, todo o tráfego externo recebido pelos nós do GKE é negado.

Para controlar a comunicação entre sub-redes, é necessário criar regras de firewall que permitam a passagem de tráfego entre as sub-redes. Use a sinalização --tags durante a criação do cluster ou do pool de nós para marcar com tag corretamente os nós do GKE e efetivar as regras de firewall. Você também pode usar tags para criar rotas entre suas sub-redes, se necessário.

Clusters zonais e regionais

É possível criar clusters Standard e do Autopilot. Os clusters do Autopilot são clusters regionais. Os clusters padrão são regionais ou zonais. Os clusters zonais podem ser de zona única ou multizonal. Os clusters regionais e multizonais distribuem recursos em várias zonas de uma região, o que pode melhorar a disponibilidade e a resiliência dos clusters.

Os clusters zonais têm as seguintes propriedades:

  • Criam uma réplica do plano de controle executada em uma única zona.
  • Se forem multizonais, executam nós em várias zonas.

Os clusters regionais têm as seguintes propriedades:

  • Replicam planos de controle em três zonas.
  • Podem executar nós em várias zonas ou em uma única zona, dependendo dos locais dos nós configurados.

No momento da criação do cluster, é possível criar clusters zonais ou regionais. É possível adicionar novas zonas a um cluster atual para torná-lo um cluster de várias zonas. No entanto, não é possível alterar o cluster zonal existente para ser regional, e não é possível alterar o cluster regional para zonal.

A disponibilidade de serviço dos nós nos clusters gerenciados pelo GKE é coberta pelo Contrato de nível de serviço (SLA, na sigla em inglês) do Compute Engine.

Para saber mais sobre clusters regionais e zonais, consulte a documentação do GKE.

Como gerenciar identidades e acesso

Papéis e grupos do Identity and Access Management (IAM)

Além de conceder papéis do IAM a usuários individuais, também é possível usar grupos para simplificar a aplicação de papéis.

A ilustração a seguir de um layout de política do IAM mostra o princípio do menor privilégio de um projeto dev configurado para desenvolvedores desenvolverem e testarem os próximos recursos e correções de bugs, bem como um projeto prod para tráfego de produção:

Gerenciamento de identidade e acesso

Como mostra a tabela a seguir, há quatro grupos de usuários dentro da organização com diferentes níveis de permissões, concedidas por papéis de IAM entre os dois projetos:

Equipe Papel de IAM Projeto Permissões
Desenvolvedores roles/container.developer dev Pode criar recursos do Kubernetes para os clusters existentes no projeto, sem permissão para criar ou excluir clusters.
Operações roles/container.admin prod Acesso administrativo completo aos clusters e recursos do Kubernetes em execução no projeto.
Segurança roles/container.viewer
roles/compute.securityAdmin
prod Criar, modificar e excluir regras de firewall e certificados SSL, bem como ver os recursos que foram criados dentro de cada cluster, incluindo os registros dos pods em execução.
Rede roles/compute.networkAdmin prod Criar, modificar e excluir recursos de rede, exceto regras de firewall e certificados SSL.

Além das três equipes com acesso ao projeto prod, uma conta de serviço extra é fornecida ao papel container.developer de prod, concedendo permissão para criar, listar e excluir recursos no cluster. As contas de serviço podem ser usadas para dar a scripts de automação ou bibliotecas de implantação a capacidade de agir por você. As implantações no projeto de produção e nos clusters devem passar por um pipeline automatizado.

No projeto dev, há vários desenvolvedores trabalhando no mesmo aplicativo no mesmo cluster. Isso é facilitado pelos namespaces, que o usuário do cluster pode criar. Cada desenvolvedor pode criar recursos dentro do próprio namespace, o que evita conflitos de nome. Eles também podem reutilizar os mesmos arquivos de configuração YAML nas implantações para manter a maior semelhança possível entre as configurações durante as iterações de desenvolvimento.

Os namespaces também podem ser usados para criar cotas para uso de CPU, memória e armazenamento no cluster, assegurando que um desenvolvedor não esteja usando recursos demais no cluster. Para mais informações sobre como usar namespaces, consulte Práticas recomendadas do Kubernetes: especificar namespaces em YAML (em inglês).

A próxima seção aborda como restringir que usuários operem em determinados namespaces.

Controle de acesso baseado em papéis

Os clusters do GKE que executam o Kubernetes 1.6 e versões posteriores podem utilizar outras restrições relativas ao que os usuários estão autorizados a fazer em clusters individuais. O IAM pode fornecer aos usuários acesso a clusters e aos recursos dentro deles. No entanto, o controle de acesso baseado em papéis do Kubernetes (RBAC, na sigla em inglês) permite usar a API Kubernetes para limitar ainda mais as ações que os usuários podem executar nos próprios clusters.

Com o RBAC, os administradores de cluster aplicam políticas detalhadas a namespaces individuais dentro dos próprios clusters ou ao cluster como um todo. A ferramenta kubectl do Kubernetes usa as credenciais ativas da ferramenta gcloud, permitindo que os administradores de cluster mapeiem papéis para identidades do Google Cloud (usuários, contas de serviço e Grupos do Google) como sujeitos em RoleBindings.

Os Grupos do Google para RBAC permitem que você use grupos com o RBAC do Kubernetes. Para usar esse recurso, você precisa configurar Grupos do Google no Google Workspace, criar um cluster com o recurso ativado e usar RoleBindings para associar os grupos aos papéis que você quer vincular a eles. Para mais informações, consulte Controle de acesso baseado em papéis.

Por exemplo, na figura a seguir, há dois usuários, user-a e user-b, que receberam os papéis config-reader e pod-reader no namespace app-a.

Autorização RBAC.

Como em outro exemplo, o Google Cloud tem papéis de IAM em nível do projeto que dão a certos usuários acesso a todos os clusters de um projeto. Além disso, são adicionadas vinculações individuais de papel (em nível de namespace e de cluster) por meio do RBAC para dar acesso detalhado a recursos dentro de clusters ou namespaces específicos.

Vinculações de papéis de IAM.

O Kubernetes inclui alguns papéis padrão, mas como administrador de cluster, você pode criar o próprio mapa, mais específico às necessidades organizacionais. O exemplo de papel a seguir permite que os usuários vejam, editem e atualizem o ConfigMaps, mas não os excluam porque o verbo delete não está incluído:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: config-editor
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Depois de definir os papéis, aplique-os ao cluster ou namespace por meio de vinculações. As vinculações associam os papéis aos respectivos usuários, grupos ou contas de serviço. O exemplo a seguir mostra como vincular um papel criado anteriormente (config-editor) ao usuário bob@example.org e ao namespace development.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: config-editors
  namespace: development
subjects:
- kind: User
  name: bob@example.org
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: config-editor
  apiGroup: rbac.authorization.k8s.io

Para mais informações sobre o RBAC, consulte a documentação do GKE.

Acesso e compartilhamento de imagens

As imagens no Container Registry ou no Artifact Registry são armazenadas no Cloud Storage.

Nesta seção, discutiremos as seguintes maneiras de compartilhar imagens:

  • Tornar as imagens públicas.
  • Compartilhe imagens entre projetos.

O uso do Artifact Registry é importante se você ativar clusters particulares. Em clusters particulares, o ambiente de execução do contêiner do cluster não pode extrair imagens de contêiner diretamente de um Container Registry externo, a menos que você configure um Cloud NAT. O ambiente de execução do contêiner pode extrair imagens do Artifact Registry em um cluster particular sem um Cloud NAT ou Acesso privado do Google. É necessário colocar os nós em uma sub-rede com o Acesso privado do Google ativado se eles precisarem se comunicar diretamente com o Artifact Registry (por exemplo, os nós precisam criar novos artefatos e armazená-los no Artifact Registry). Para mais informações, consulte Como extrair imagens de contêiner de um registro de imagem.

Como tornar as imagens públicas no Artifact Registry

Para tornar as imagens públicas, torne os objetos e buckets deles públicos no Artifact Registry. Para instruções mais detalhadas, consulte a documentação de controle de acesso do Container Registry.

Se você precisar usar imagens públicas, considere validar o conjunto de imagens públicas que podem ser implantadas nos clusters. Para mais informações, consulte a seção Autorização binária.

Como acessar imagens em projetos no Artifact Registry

É possível compartilhar imagens de contêiner entre projetos, basta garantir que os nós do Kubernetes usem uma conta de serviço. É possível conceder à conta de serviço acesso como um storage.viewer nos projetos em que você quer usar o Artifact Registry. Use uma conta de serviço personalizada com permissões restritas, porque a conta de serviço padrão tem acesso de editor a todo o projeto.

Para usar uma conta de serviço diferente para os clusters, forneça a conta de serviço ao criar o cluster ou o pool de nós usando a sinalização --service- account.

Para mais informações, consulte Como configurar o controle de acesso.

Como determinar a política de extração de imagens correta

A propriedade imagePullPolicy no Kubernetes determina se o kubelet tenta extrair uma imagem enquanto inicia um pod. Defina uma configuração apropriada do imagePullPolicy que será especificada para as imagens de contêiner. Por exemplo, é possível especificar a seguinte política de extração de imagens:

imagePullPolicy: IfNotPresent

Nesse caso, o kubelet recupera uma cópia da imagem somente se ela não estiver disponível no cache do nó.

Para mais informações sobre as possíveis políticas de extração de imagens que podem ser especificadas, consulte Imagens de contêiner na documentação do Kubernetes.

Como usar controladores de admissão dinâmica para aplicar políticas

Os controladores de admissão dinâmica fazem parte do plano de controle do Kubernetes. Eles podem interceptar solicitações recebidas feitas ao servidor de APIs. Os controladores de admissão são uma ferramenta poderosa que podem ajudar a aplicar políticas personalizadas específicas à empresa nos clusters do GKE.

O Kubernetes é compatível com dois tipos de controladores de admissão: controladores de admissão de mutação e controladores de admissão de validação.

Os controladores de admissão de mutação podem interceptar solicitações de admissão e pode silenciar (alterar) a solicitação. A solicitação é então transmitida ao servidor de APIs.

Os controladores de admissão de validação examinam uma solicitação e determinam se ela é válida de acordo com as regras especificadas. Se algum controlador de admissão de validação for configurado no cluster, ele será invocado depois que a solicitação for validada pelo servidor de APIs. Os controladores de admissão de validação podem rejeitar solicitações para garantir a conformidade com as políticas definidas no controlador.

Por exemplo, é possível aplicar uma política de extração de imagens usando um controlador de admissão de mutação para garantir que a política esteja definida como Always, independentemente da configuração imagePullPolicy especificada pelos desenvolvedores que enviaram solicitações de criação de pods.

Como usar apps pré-empacotados do Google Cloud Marketplace

Também é possível implantar apps pré-compactados do Kubernetes do Google Cloud Marketplace. Os aplicativos do Kubernetes listados no Google Cloud Marketplace são testados e verificados pelo Google, incluindo a verificação de vulnerabilidades e contratos de parceiros para manutenção e suporte.

Como usar a Identidade da carga de trabalho para interagir com APIs de serviço do Google Cloud

Geralmente, as arquiteturas empresariais envolvem componentes de arquitetura que abrangem serviços de nuvem, como serviços gerenciados em nuvem e serviços hospedados. Um padrão comum para seus aplicativos ou serviços do GKE precisa se comunicar com os serviços gerenciados do Google Cloud, como o Cloud Storage e o BigQuery. Como exemplo, talvez seja necessário armazenar registros de clientes depois que eles forem processados por jobs em lote no GKE no BigQuery para análise posterior.

A Identidade da carga de trabalho permite que uma conta de serviço do Kubernetes no cluster do GKE atue como uma conta de serviço do IAM. Os pods que usam a conta de serviço configurada do Kubernetes serão autenticados automaticamente como a conta de serviço do IAM ao acessar as APIs do Google Cloud. Observe que isso pressupõe que você concedeu o nível de acesso necessário para o serviço à conta de serviço do Google Cloud.

Como gerenciar a segurança do cluster

A segurança é uma matéria multifacetada de suma importância em implantações empresariais de clusters do GKE. Nesta seção, abordamos vários fatores que podem ser usados para aumentar a segurança do cluster.

Verificação de vulnerabilidades de imagens

O Artifact Registry pode verificar nas imagens vulnerabilidades de segurança conhecidas. As imagens compatíveis incluem Ubuntu, Debian, RedHat e outras. Consulte Fontes de vulnerabilidade para ver a lista completa. Recomendamos que você verifique as imagens que planeja usar nos clusters do GKE.

Se possível, ative o Container Analysis para reduzir ainda mais os riscos de segurança.

Para visualizar vulnerabilidades de uma imagem, consulte Como verificar imagens automaticamente.

Sua organização pode se beneficiar da automatização do rastreamento e do recebimento de notificações quando alterações são feitas no repositório do Artifact Registry. Por exemplo, é possível ser notificado quando uma imagem for criada ou excluída. É possível criar um pipeline em que os listeners do aplicativo estejam inscritos em um tópico do Pub/Sub em que os eventos do Artifact Registry são publicados. Use esses eventos para acionar versões ou implantações automatizadas. Para mais informações, consulte a documentação do Artifact Registry.

Autorização binária

Com o Kubernetes, é preciso determinar se e quando uma imagem deve ser considerada válida para implantação no cluster. Para esta tarefa, é possível usar a autorização binária. Essa é uma construção de tempo de implantação que permite definir um fluxo de trabalho que impõe as assinaturas (atestados) que uma imagem precisa ter para ser implantada no cluster.

O fluxo de trabalho é definido em termos de políticas. À medida que você move o código e, portanto, a imagem do contêiner por meio de um pipeline de CI/CD, a autorização binária registra atestados para cada um desses estágios, conforme definido na política de autorização binária. Esses atestados validam que uma imagem passou pelos marcos definidos.

A autorização binária se integra à API de implantação do GKE e pode garantir que a implantação de uma imagem esteja sujeita a todos os atestados necessários. As tentativas de implantação com falha são automaticamente registradas, e os administradores de cluster podem analisá-las e auditá-las.

Para um tutorial sobre como implementar a autorização binária para o GKE usando o Cloud Build, consulte Como implementar a autorização binária usando o Cloud Build e o GKE.

Acesso seguro com o gVisor no GKE Sandbox

Um contêiner fornece uma camada de segurança e isolamento de kernel, mas ainda pode estar vulnerável a violações que levam os invasores a ter acesso ao sistema operacional (SO) do host. Uma abordagem mais resiliente para o isolamento de segurança entre um contêiner e seu SO host é criar outra camada de separação. Uma abordagem é usar o GKE Sandbox.

O GKE Sandbox usa o gVisor, um ambiente de execução de contêiner de código aberto que foi lançado pelo Google. Internamente, o gVisor cria um kernel virtual para os contêineres interagirem, o que abstrai o alcance que um contêiner tem para o kernel do host. Além disso, ele impõe controle sobre as operações de arquivo e rede que o contêiner pode executar.

Como o GKE Sandbox cria uma camada adicional de isolamento, ele pode gerar mais memória e sobrecarga de CPU. Antes de usar o GKE Sandbox, pense em quais cargas de trabalho precisam desse nível elevado de segurança. Normalmente, bons candidatos são serviços baseados em imagens externas.

Para informações sobre como criar um pool de nós com o GKE ativado, consulte Como aumentar o isolamento de cargas de trabalho com o GKE Sandbox.

Registro de auditoria

A geração de registros de auditoria do Kubernetes registra todas as solicitações de API feitas ao servidor da API Kubernetes. Essa geração de registros é útil para ajudar você a detectar anomalias e padrões incomuns de configuração e acesso. Estes são alguns exemplos do que você pode verificar e alertar:

  • Como excluir uma implantação.
  • Como anexar ou usar exec para acessar um contêiner que tenha acesso com privilégios.
  • Como modificar objetos ClusterRole ou criar vinculações de papéis para os papéis do cluster.
  • Como criar contas de serviço no namespace kube-system.

O GKE integra a geração de registros de auditoria do Kubernetes com os Registros de auditoria do Cloud e o Cloud Logging. É possível acessar esses registros da mesma forma que você acessa registros de recursos executados no projeto do Cloud. As solicitações de API feitas ao servidor da API Kubernetes podem ser registradas, e é possível usá-las para revisar os padrões de atividade da API.

Cada solicitação (evento) que é capturada pelo servidor da API Kubernetes é processada usando uma ou mais políticas definidas por você. Elas podem ser políticas de auditoria do Kubernetes que determinam quais eventos são registrados ou podem ser políticas de auditoria do Google Kubernetes Engine que determinam se os eventos são registrados no registro de atividades do administrador ou no registro de dados. Os registros de atividades administrativas são ativados por padrão. Você também poderá ativar a geração de registros de acesso a dados se precisar registrar detalhes sobre quais metadados e dados foram lidos ou gravados nos clusters. Observe que ativar a geração de registros de acesso a dados pode gerar cobranças adicionais. Para mais informações, consulte a documentação sobre preços.

Políticas de segurança de pods

Um vetor de ataque comum serve para implantar pods com privilégios encaminhados em uma tentativa de conseguir acesso a um cluster do Kubernetes. O Gatekeeper é um controlador de admissão que usa políticas que descrevem o que um pod pode fazer. É possível usá-lo para restringir o acesso aos uso dos namespaces, como os tipos de volume e os recursos do SO subjacentes.

Considerações sobre segurança de contêiner

O elemento básico dos serviços do Kubernetes é o contêiner. Isso torna a segurança do contêiner um fator importante ao planejar a segurança e as políticas do cluster. Considere cuidadosamente o seguinte:

  • As imagens que você usa para criar seus contêineres.
  • Os privilégios que você atribui a contêineres.
  • Como os contêineres interagem com o SO do host e outros serviços.
  • Como os contêineres acessam e registram informações confidenciais.
  • Como você gerencia o ciclo de vida dos contêineres nos clusters.

Para mais informações e práticas recomendadas, consulte a documentação sobre como criar e operar contêineres.

Como configurar a rede

O Kubernetes fornece uma abstração de serviço que inclui balanceamento de carga e descoberta de serviços em conjuntos de pods dentro de um cluster, bem como em sistemas legados que estão sendo executados fora do cluster. As seções a seguir descrevem as práticas recomendadas para a comunicação entre os pods do Kubernetes e com outros sistemas, incluindo outros clusters do Kubernetes.

Clusters nativos de VPC em comparação com clusters baseados em rotas

Com base em como os clusters do GKE encaminham o tráfego de um pod para outro, os clusters podem ser categorizados em dois tipos.

  • Um cluster que usa intervalos de IP de alias para rotear tráfego, chamado de cluster nativo de VPC.
  • Um cluster que usa o Google Cloud Routes, chamado de cluster baseado em rotas.

Os clusters nativos de VPC usam intervalos de IP de alias para redes de pods. Isso significa que o plano de controle gerencia automaticamente a configuração de roteamento para pods em vez de configurar e manter rotas estáticas para cada nó no cluster do GKE. Usando intervalos de IP do alias, é possível configurar vários endereços IP internos que representam contêineres ou aplicativos hospedados em uma VM, sem a necessidade de definir uma interface de rede separada. O Google Cloud instala automaticamente rotas de rede VPC para intervalos de IP primários e de alias para a sub-rede da interface de rede principal. Isso simplifica muito o roteamento de tráfego entre pods.

Além disso, os clusters nativos de VPC não estão sujeitos a cotas de rota. O uso de intervalos de IP do alias na estrutura do cluster fornece acesso direto aos Serviços do Google, como o Cloud Storage e o BigQuery. Caso contrário, esse acesso seria possível apenas com um gateway NAT.

É um padrão comum as empresas fazer com que os clusters do GKE se comuniquem com segurança com o ecossistema local de aplicativos e serviços. Os intervalos de IP do alias permitem isso porque os endereços IP do alias são detectáveis pelo Cloud VPN ou pelo Cloud Interconnect. Isso ajuda a oferecer conectividade segura em toda a infraestrutura local e no Google Cloud.

Você precisa decidir qual tipo de cluster é mais adequado à sua topologia de rede. Os principais fatores são a disponibilidade de endereços IP na sua rede, planos de expansão de cluster (nós) na sua empresa e conectividade com outros aplicativos no ecossistema. Os clusters nativos de VPC tendem a consumir mais endereços IP na rede, portanto, leve isso em consideração. Observe que não é possível migrar um cluster nativo de VPC para um cluster com base em rota após a criação e um cluster baseado em rota para um cluster nativo de VPC. Portanto, é importante entender as implicações de sua escolha antes de implementá-la.

Redes autorizadas para acesso ao plano de controle

A opção de redes autorizadas restringe o acesso ao endpoint do plano de controle (o servidor da API) dos intervalos CIDR especificados e garante que somente as equipes na rede possam administrar o cluster.

Esses recursos têm os seguintes requisitos:

  • Apenas 50 intervalos CIDR são permitidos.
  • Se você estiver usando um pipeline de CI/CD, para permitir que as ferramentas de CI/CD tenham acesso ao servidor da API do cluster, adicione os endereços IP ou o intervalo CIDR delas à lista de permissões (consulte visão geral das regras de firewall da VPC).

Clusters particulares

Por padrão, todos os nós em um cluster do GKE têm endereços IP públicos. Uma prática recomendada é criar clusters particulares, que fornecem a todos os nós de trabalho apenas endereços IP RFC 1918 particulares. Os clusters particulares impõem o isolamento da rede, reduzindo a superfície de exposição ao risco dos clusters. Usar clusters particulares significa que, por padrão, somente os clientes dentro da sua rede podem acessar os serviços no cluster. Para permitir que serviços externos alcancem serviços no seu cluster, use um balanceador de carga HTTP(S) ou um balanceador de carga de rede.

Quando você quiser liberar o acesso ao plano de controle fora da rede VPC, use clusters particulares com redes autorizadas. Quando você ativa redes autorizadas, o endpoint do plano de controle do cluster recebe dois endereços IP, um interno (particular) e um público. O endereço IP interno pode ser usado por qualquer coisa interna na rede que esteja dentro da mesma região. O endereço IP público do plano de controle pode ser usado por qualquer usuário ou processo externo à rede e proveniente de um intervalo CIDR ou endereço IP permitido. Também é possível usar esse recurso em conjunto com o Cloud Interconnect ou o Cloud VPN para permitir o acesso ao nó do plano de controle somente dentro do data center particular.

Proteção contra exfiltração de dados

Além disso, é possível usar o VPC Service Controls para ajudar a reduzir o risco de exportação de dados. O VPC Service Controls ajuda a proteger os serviços gerenciados do Google Cloud em um ou mais projetos, permitindo que você defina um perímetro de serviço para acessar esses serviços. É possível conceder aos aplicativos executados nos clusters do GKE acesso a esses serviços gerenciados configurando os níveis de acesso apropriados. Use também os VPC Service Controls para proteger o plano de controle de criação de clusters do GKE.

Comunicar-se no mesmo cluster

Descoberta de serviço

O Kubernetes permite definir serviços que agrupam pods em execução no cluster com base em um conjunto de rótulos. Esse grupo de pods pode ser descoberto no cluster usando DNS. Para mais informações sobre a descoberta de serviços no Kubernetes, acesse a documentação Como conectar aplicativos com serviços.

DNS

Um servidor DNS de cluster local, kube-dns, é implantado em cada cluster do GKE que manipula o mapeamento de nomes de serviço para IPs de pods íntegros. Por padrão, o servidor DNS do Kubernetes retorna o endereço IP do cluster do serviço. Esse endereço IP é estático por toda a vida do serviço. Ao enviar tráfego a esse IP, os iptables no nó fazem o balanceamento de carga dos pacotes pelos pods prontos que correspondem aos seletores do serviço. Esses iptables são programados automaticamente pelo serviço kube-proxy em execução em cada nó.

Para mais informações sobre o kube-dns, consulte Descoberta de serviços e DNS. Para informações sobre escalonamento, consulte Escalonamento de DNS.

Fluxo de pacotes: ClusterIP

O diagrama a seguir mostra a resposta DNS e o fluxo de pacotes de um serviço padrão do Kubernetes. Os endereços IP do pod são roteáveis de fora do cluster, mas o endereço IP do cluster de um serviço só é acessível dentro do cluster. Esses endereços IP virtuais são implementados por meio da conversão de endereços de rede de destino (DNAT, na sigla em inglês) em cada nó do Kubernetes. O serviço kube-proxy em execução nos nós mantém as regras de encaminhamento atualizadas em cada nó que mapeia o endereço IP do cluster para os endereços IP de pods íntegros no cluster. Se houver um pod do serviço em execução no nó local, esse pod será usado. Caso contrário, será escolhido um pod aleatório no cluster.

Serviço de IP de cluster.

Para mais informações sobre como o ClusterIP é implementado, acesse a documentação do Kubernetes.

Serviços sem comando

Se você quer a descoberta de serviço e o monitoramento de integridade, mas prefere que o serviço DNS retorne os endereços IP dos pods em vez de um endereço IP virtual, provisione o serviço com o campo ClusterIP definido como None, o que torna o serviço sem comando.

Nesse caso, o servidor DNS retorna uma lista de registros A que mapeiam o nome DNS do serviço para os registros A dos pods prontos que correspondem aos seletores de rótulo definidos pelo serviço. Os registros da resposta se alternam para facilitar a propagação da carga em vários pods. Algumas ferramentas de resolução de DNS do lado do cliente podem armazenar respostas de DNS em cache, tornando ineficaz a alternância do registro A. As vantagens de usar ClusterIP estão listadas na documentação do Kubernetes. Para mais informações sobre como usar o ClusterIP no GKE, consulte Como expor aplicativos usando serviços.

Um caso de uso típico para serviços sem comando é StatefulSets. StatefulSets é ideal para executar aplicativos com estado que exigem estabilidade de armazenamento e rede entre as réplicas. Esse tipo de implantação provisiona pods que têm uma identidade de rede estável, o que significa que os respectivos nomes de host podem ser resolvidos no cluster. O IP do pod pode mudar, mas a entrada DNS do nome do host permanecerá atualizada e poderá ser resolvida.

Veja a seguir um exemplo da resposta DNS e do padrão de tráfego em um serviço sem comando. Os endereços IP do pod podem ser roteados por meio das tabelas de rotas da sub-rede do Google Cloud padrão e são acessados diretamente pelo seu aplicativo.

Exemplo de resposta DNS e padrão de tráfego do serviço sem comando.

Políticas de rede

Use a aplicação da política de rede do GKE para controlar a comunicação entre os pods e os serviços do cluster. Para definir uma política de rede no GKE, use a API Kubernetes Network Policy para criar regras de firewall no nível do pod. Essas regras de firewall determinam quais pods e serviços podem acessar um ao outro dentro do cluster.

As políticas de rede melhoram a segurança das cargas de trabalho em execução no cluster. Por exemplo, é possível criar uma política de rede para garantir que um serviço comprometido de front-end no aplicativo não possa se comunicar diretamente com um serviço de cobrança ou contabilidade vários níveis abaixo.

Também é possível usar políticas de rede para isolar cargas de trabalho pertencentes a locatários diferentes. Por exemplo, é possível fornecer multilocação segura definindo um modelo em que há um locatário para cada namespace. Nesse modelo, as regras de política de rede podem garantir que pods e serviços em um determinado namespace não acessem outros pods ou serviços em um namespace diferente.

Como se conectar a um cluster do GKE usando o Google Cloud

Para se conectar aos serviços de fora do cluster, mas dentro do espaço de endereço IP privado da rede do Google Cloud, use o balanceamento de carga interno. Durante a criação de um serviço com type: Load Balancer e de uma anotação cloud.google.com/load-balancer-type: Internal no Kubernetes, um balanceador de carga de rede interno é criado no projeto do Google e configurado para distribuir o tráfego TCP e UDP entre os pods.

Como se conectar a serviços externos de dentro de um cluster

Em muitos casos, pode ser necessário conectar os aplicativos em execução dentro do Kubernetes a um serviço, banco de dados ou aplicativo que esteja fora do cluster. Você tem três opções, conforme descrito nas seções a seguir.

OpçãoDescrição
Domínios stubNo Kubernetes 1.6 e posterior, é possível configurar o serviço DNS interno do cluster (`kube-dns`) para encaminhar consultas DNS referentes a um determinado domínio a um servidor DNS externo. Isso é útil quando você tem servidores DNS autoritativos que precisam ser consultados em relação a um domínio que os pods do Kubernetes precisam usar.
Serviços de nomes externosOs serviços de nomes externos permitem mapear um registro DNS para um nome de serviço dentro do cluster. Nesse caso, as buscas DNS quanto ao serviço no cluster retornarão um registro CNAME que você escolher. Use-o se você tiver apenas alguns registros dos quais quer fazer o mapeamento retroativo aos serviços DNS existentes.
Serviços sem seletoresVocê pode criar serviços sem seletor e depois adicionar a eles os pontos de extremidade manualmente para preencher a descoberta de serviço com os valores corretos. Com isso, você pode usar o mesmo mecanismo de descoberta de serviço para os serviços internos ao cluster, ao mesmo tempo em que assegura que os sistemas sem descoberta de serviço por meio do DNS ainda estão acessíveis. Essa abordagem é a mais flexível, mas também requer mais configuração e manutenção a longo prazo.

Para mais informações sobre DNS, acesse a página de documentação Pods e serviços DNS do Kubernetes.

Como configurar seus serviços no Kubernetes para receber tráfego da Internet

Os serviços do Kubernetes podem ser expostos usando NodePort, ClusterIP e LoadBalancer.

No entanto, quando você tem muitos serviços externos, pode usar o recurso de entrada do Kubernetes. O Ingress fornece um ponto de entrada para o cluster e permite definir regras de roteamento que encaminham solicitações recebidas para um ou mais serviços de back-end no cluster. No GKE, o controlador Ingress do GKE implementa um recurso Ingress como balanceador de carga HTTP(S) do Google Cloud e o configura de acordo com as informações no recurso Ingress e nos serviços associados. Para mais informações, consulte Configuração do Ingress para balanceamento de carga externo.

Um recurso de entrada do Kubernetes só pode ser usado quando os aplicativos veiculam tráfego por HTTP(S). Se os serviços de back-end usam protocolos TCP ou UDP, use um balanceador de carga de rede. Isso pode ser necessário, por exemplo, se você precisar expor seu banco de dados como um serviço.

Configuração de back-end

Um BackendConfig é uma definição de recurso personalizada que pode fornecer uma configuração adicional que é usada pelo controlador Ingress do Kubernetes. Quando você implanta um objeto Ingress no cluster do GKE, o controlador Ingress do Kubernetes configura um balanceador de carga HTTP(S) que encaminha solicitações recebidas para os serviços de back-end conforme especificado no manifesto do Ingress.

É possível complementar a configuração do balanceador de carga com especificações como estas:

  • Como ativar o armazenamento em cache com o Cloud CDN.
  • Como adicionar endereços IP ou listas de permissões CIDR com o Google Cloud Armor.
  • Como controlar o acesso no nível do aplicativo com o Identity-Aware Proxy (IAP).
  • Configurar tempos limite de serviço e tempos limite de diminuição de conexão para serviços que são regidos pelo objeto Ingress em um cluster.

Para mais informações sobre como configurar o recurso personalizado BackendConfig no GKE, consulte Recursos de Entrada.

Como usar uma malha de serviço

Uma malha de serviço fornece uma maneira uniforme de conectar, proteger e gerenciar microsserviços em execução nos clusters do Kubernetes. Por exemplo, a malha de serviço do Istio, que pode ser adicionada como um complemento do GKE, pode gerenciar a autenticação e a comunicação de serviço a serviço, aplicar políticas de acesso e coletar pontos de dados de telemetria avançados que podem ser usados para auditar e administrar os clusters do GKE.

Os principais recursos que uma malha de serviço fornece são os seguintes:

  • Gerenciamento de tráfego. A malha de serviço permite definir regras granulares que determinam como o tráfego é roteado e dividido entre serviços ou entre versões diferentes do mesmo serviço. Isso facilita o lançamento de implantações canário e azul-verde.

  • Observabilidade integrada. A malha registra as métricas de tráfego de rede (Camada 4 e Camada 7) de maneira uniforme, sem a necessidade de escrever código para instrumentar seus serviços.

  • Segurança. A malha permite TLS mútuo (mTLS) entre serviços. Ele não apenas fornece canais seguros para dados em trânsito, mas também ajuda você a gerenciar a autenticação e a autorização de serviços na malha.

Em resumo, as malhas de serviço como o Istio permitem delegar tarefas no nível do sistema à infraestrutura da malha. Isso melhora a agilidade geral, a robustez e a união de serviços em execução nos clusters do Kubernetes.

Para informações sobre como usar uma malha de serviço com o Anthos, consulte Sobre o Anthos Service Mesh.

Firewall

Os nós do GKE são provisionados como instâncias no Compute Engine. Portanto, eles seguem o mesmo mecanismo de firewall com estado que outras instâncias. Essas regras de firewall são aplicadas dentro da rede a instâncias com o uso de tags. Cada pool de nós recebe o próprio conjunto de tags que pode ser usado nas regras. Por padrão, cada instância pertencente a um pool de nós recebe uma tag que identifica um cluster específico do Kubernetes Engine do qual esse pool de nós faz parte. Essa tag é usada em regras de firewall criadas automaticamente pelo Kubernetes Engine. É possível adicionar suas próprias tags personalizadas no momento de criação do pool de nós ou do cluster usando a sinalização --tags na ferramenta gcloud.

Por exemplo, para permitir que um balanceador de carga interno acesse a porta 8080 em todos os nós, use os comandos a seguir:

gcloud compute firewall-rules create allow-8080-fwr \
    --target-tags allow-8080 \
    --allow tcp:8080 \
    --network gke \
    --source-range 130.211.0.0/22
gcloud container clusters create my-cluster --tags allow-8080

O exemplo a seguir mostra como marcar um cluster para que o tráfego da Internet possa acessar nós na porta 30000 enquanto o outro cluster é marcado para permitir o tráfego da VPN para a porta 40000. Isso é útil ao expor um serviço por meio de um NodePort que só deve ser acessível por redes com privilégio, como uma VPN, em direção a um data center corporativo ou de outro cluster no projeto.

Como marcar dois clusters de maneira diferente.

Como se conectar a um data center local

Use o Cloud Interconnect ou o Cloud VPN para se conectar a data centers locais. Por não serem opções mutuamente excludentes, é possível combiná-las de acordo com a carga de trabalho e os requisitos: As opções são as seguintes:

  • Use a Interconexão dedicada para transferir grandes quantidades de dados entre redes, com baixa latência.

  • Use a Interconexão por parceiro caso o data center não esteja em uma instalação de colocation de Interconexão dedicada. O Google tem mais de 100 pontos de presença (PoPs, na sigla em inglês) que se conectam a provedores de serviços em todo o mundo.

  • Use o peering direto para cargas de trabalho que exigem largura de banda dedicada, são vulneráveis à latência e precisam de acesso ao Google Workspace e às APIs compatíveis do Google. O peering direto é uma conexão de camada 3, efetuada pela troca de rotas BGP e, portanto, requer um ASN registrado.

  • Use o peering por operadora se você não tiver um ASN registrado ou tiver relações com um provedor de serviços preferencial. O peering por operadora é o mesmo que peering direto, só que feito por um provedor de serviços.

  • Use o Cloud VPN se a criptografia IPSec for obrigatória ou se você quiser estender sua rede particular à rede particular do Compute Engine. O Cloud VPN é configurado na interconexão de camada 3 e nas opções de Internet (1, 2 e 3).

Como gerenciar a operabilidade do cluster

Esta seção discute os principais fatores a serem considerados ao administrar e operar seus clusters do GKE.

Cotas de recursos

As cotas de recursos do Kubernetes fornecem restrições que limitam o consumo de recursos permissivo agregado de cada namespace em um cluster. Se você tiver clusters com namespaces do Kubernetes que isolam funções de negócios ou estágios de desenvolvimento, use cotas para limitar uma ampla variedade de recursos, como utilização da CPU, memória ou o número de pods e serviços. que podem ser criadas em um namespace. Para garantir a estabilidade do plano de controle dos clusters do GKE, o Kubernetes aplica automaticamente cotas de recursos padrão e não substituíveis a cada namespace em qualquer cluster do GKE com cinco nós ou menos.

Limites de recurso

Use o objeto LimitRange do Kubernetes para impor restrições granulares nos limites mínimo e máximo de recursos com que os contêineres e pods podem ser criados. O exemplo a seguir mostra como usar o LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: sample-limits
spec:
  limits:
    - max:
        cpu: "400m"
        memory: "1Gi"
      defaultRequest:
        cpu: "200m"
        memory: "500Mi"
      type: Container

Orçamentos de interrupção do pod

Os orçamentos de interrupção de pod (PDB, na sigla em inglês) ajudam a proteger contra exclusão voluntária ou acidental de pods ou implantações pela sua equipe. Os PDBs não podem evitar interrupções involuntárias que podem ser causadas pela interrupção ou reinicialização do nó. Normalmente, um operador cria um PDB para um aplicativo que define o número mínimo de réplicas dos pods para o aplicativo.

Em uma empresa em que os desenvolvedores trabalham em vários aplicativos, ocorrem erros. Portanto, um desenvolvedor ou administrador talvez execute acidentalmente um script que exclua pods ou implantações. Em outras palavras, que exclua os recursos do Kubernetes. Mas, ao definir um PDB, você ajuda a garantir um conjunto mínimo viável de recursos para seus aplicativos do Kubernetes.

Os PDBs configurados para os clusters do GKE são respeitados durante os upgrades do GKE. Isso significa que é possível controlar a disponibilidade dos seus aplicativos durante um upgrade. O exemplo a seguir mostra como configurar um PDB.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
  spec:
    minAvailable: 4
    selector:
      matchLabels:
        app: nginx

Como gerenciar upgrades do Kubernetes

Mantenha seus clusters do Kubernetes no GKE atualizados para a versão mais recente do Kubernetes que atenda aos seus requisitos. É possível optar por fazer upgrade do plano de controle ou dos nós automaticamente ou controlar os upgrades por conta própria.

Revise as notificações de upgrade no console, nos boletins de segurança do Anthos e nas notificações de upgrade de cluster. Se você estiver fazendo upgrade dos nós manualmente, recomendamos acionar o upgrade da versão depois de revisar o conteúdo de lançamento e testar os aplicativos em um cluster no sandbox que esteja em execução na versão para a qual você quer fazer upgrade.

Quando um plano de controle de um cluster zonal está passando por um upgrade, ele fica indisponível. Isso significa que não é possível interagir com o servidor de API para adicionar ou remover recursos do cluster. Se não for possível arcar com o tempo de inatividade de um upgrade de um plano de controle, torne o plano de controle altamente disponível implantando clusters GKE regionais. Nessa abordagem, é possível ter vários planos de controle espalhados por zonas. Quando um plano de controle está sendo atualizado, todas as solicitações desse plano para o servidor da API são roteadas para os outros planos.

Quando um upgrade é aplicado, o GKE aplica uma atualização gradual aos nós de trabalho. Sistematicamente, ele esvazia, diminui e faz upgrade de um nó por vez quando um novo nó de substituição fica disponível para responder a solicitações recebidas.

Reparo automático de nós

O recurso de reparo automático de nós do GKE gerencia as verificações de integridade dos nós do GKE. Se algum dos nós for considerado não íntegro, o GKE iniciará o processo de reparo do nó.

Se o cluster do GKE tiver vários pools de nós, o recurso de reparo automático oferece controle granular sobre os pools de nós em que você quer ativar o reparo automático de nós.

Escalonamento automático de clusters do GKE

As empresas geralmente enfrentam cargas de entrada variadas nos aplicativos em execução nos clusters do Kubernetes. Para responder a essas mudanças orientadas a negócios, permita que os clusters do GKE respondam automaticamente e aumentem e diminuam com base nas métricas.

O escalonamento automático inclui várias dimensões, conforme discutido nas seções a seguir.

Escalonador automático de cluster

O escalonador automático de cluster do GKE adiciona e remove automaticamente os nós do cluster, dependendo da demanda das cargas de trabalho. O escalonador automático de cluster está ativado para pools de nós individuais. Para cada pool de nós, o GKE verifica se há pods que estão aguardando para serem programados devido à falta de capacidade. Em caso afirmativo, o escalonador automático de cluster adiciona nós ao pool de nós.

O escalonador automático de cluster reduzir escala vertical ou escalona verticalmente com base nas solicitações de recursos. Se um nó for subutilizado e se os pods em execução puderem ser programados em outros nós que tenham capacidade, o nó subutilizado será drenado e encerrado.

Para definir os limites de um pool de nós, especifique os nós mínimo e máximo que podem ser escalonados pelo escalonador automático de cluster.

Provisionamento automático de nós

O provisionamento automático de nós permite que o escalonador automático de cluster do GKE provisione automaticamente os pools de nós extras quando o escalonador automático determinar que são necessários. O escalonador automático de cluster também pode excluir pools de nós provisionados automaticamente quando não há nós nesses pools.

As decisões de provisionamento automático de nós são tomadas pelo escalonador automático de cluster do GKE com base em vários fatores. Isso inclui a quantidade de recursos solicitados pelos pods, as afinidades especificadas e as taints e tolerâncias de nós definidas no cluster do GKE.

O provisionamento automático de nós é útil se você tiver várias cargas de trabalho em execução nos clusters do GKE. Por exemplo, se o cluster do GKE tiver uma carga de trabalho dependente da GPU, será possível executá-lo em um pool de nós dedicado que é provisionado com nós habilitados para GPU. Para definir os limites de escalonamento do pool de nós, especifique um tamanho mínimo e máximo do pool de nós.

Para mais informações sobre o provisionamento automático de nós e quando ativá-lo, consulte Como usar o provisionamento automático de nós.

Escalonamento automático de pod horizontal

O Kubernetes permite criar um Escalonador automático horizontal de pods que permite configurar como as implantações do Kubernetes ou ReplicaSets precisam ser escalonadas e em quais métricas a decisão de escalonamento precisa ser baseada. Por padrão, o controlador do Escalonador automático horizontal de pods baseia as decisões de escalonamento automático na utilização da CPU. No entanto, o controlador do Escalonador automático horizontal de pods também pode calcular como os pods precisam ser escalonados com base nas métricas personalizadas, como, por exemplo, uma contagem de solicitações HTTP. Para que um Escalonador automático horizontal de pods responda a métricas personalizadas, uma instrumentação de monitoramento extra geralmente é necessária.

Para mais informações, consulte a documentação do Kubernetes e do GKE.

Escalonamento automático do pod vertical

O recurso de Escalonamento automático vertical de pods nos clusters do GKE permite descarregar a tarefa de especificar solicitações ideais de CPU e memória para contêineres. Quando necessário, o Escalonamento automático vertical de pods ajusta as alocações de recursos feitas para contêineres no cluster. O Escalonamento automático vertical de pods permite otimizar a utilização de recursos para clusters. Ele faz isso otimizando no nível do contêiner em cada nó. Isso também libera o tempo administrativo que você precisaria investir na manutenção dos seus recursos.

O Escalonamento automático vertical de pods funciona em conjunto com o recurso de provisionamento automático de nós descrito na próxima seção.

Devido às limitações do Kubernetes, as solicitações de recursos em um pod só podem ser alteradas quando um pod é reiniciado. Portanto, para fazer alterações, o Escalonamento automático vertical de pods remove o pod. Para mais informações, consulte a documentação do GKE e do Kubernetes (links em inglês).

Piloto automático

Autopilot significa que o GKE provisiona e gerencia a infraestrutura subjacente do cluster em seu nome. No Autopilot, itens como os seguintes são gerenciados:

  • Nós e pools de nós

  • provisionamento de recursos

  • Tipos de imagem de nó

  • Recursos de rede, como tipo de cluster e intervalos CIDR

  • Recursos de segurança, como a Identidade da carga de trabalho ou VMs protegidas

O Autopilot é útil para reduzir a carga operacional e não exige a configuração de itens específicos para cargas de trabalho mais complexas.

A seguir