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

Nesta solução, apresentamos um esquema e uma metodologia para integrar as cargas de trabalho ao Google Kubernetes Engine de maneira mais segura, confiável e econômica. 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.

Como estruturar projetos, redes de nuvem privada virtual (VPC) e clusters

O diagrama a seguir mostra um exemplo de uma estrutura flexível e altamente disponível para projetos, redes VPC, regiões, sub-redes, zonas e clusters.

Estrutura de projeto, rede e cluster.

Projetos

O Google Cloud cria todos os recursos próprios em uma entidade de projeto. Os projetos são a unidade de faturamento e permitem que os administradores associem os papéis do Cloud Identity and Access Management (Cloud IAM) aos usuários. Quando aplicados no nível do projeto, os papéis são pertinentes a todos os recursos encapsulados no projeto.

Use projetos para encapsular vários ambientes operacionais. Por exemplo, pode haver os projetos production e staging para equipes de operações e um projeto test-dev para desenvolvedores. É possível aplicar políticas mais granulares e estritas aos projetos que contêm os dados e cargas de trabalho mais críticos e confidenciais, ao mesmo tempo que aplica políticas de permissão flexíveis para os desenvolvedores do ambiente test-dev fazerem experiências.

Clusters

Um projeto pode conter vários clusters. Se você tiver várias cargas de trabalho para implantar, poderá optar por usar um único cluster compartilhado ou clusters separados para essas cargas de trabalho. Para tomar a melhor decisão, veja nossas práticas recomendadas no artigo sobre como escolher o tamanho e o escopo de um cluster do GKE.

Redes e sub-redes

Dentro de cada projeto, é possível 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 dentro ou fora de 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 da Internet recebido pelos nós do GKE é negado.

Para controlar a comunicação entre sub-redes, é necessário criar regras de firewall que permitam que o tráfego passe entre as sub-redes. Use a sinalização --tags durante a criação do cluster ou do pool de nós para marcar 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 de várias zonas e regionais

Por padrão, um cluster cria os respectivos mestre e nodes em uma única zona, que você especifica no momento da criação. Para melhorar a disponibilidade e a resiliência dos clusters, crie clusters de várias zonas ou regionais. Eles distribuem os recursos do Kubernetes em várias zonas dentro de uma região.

Os clusters de várias zonas:

  • criam um único mestre em uma zona;
  • criam nodes em várias zonas.

Os clusters regionais:

  • criam três mestres em três zonas;
  • por padrão, criam nodes em três zonas, mas podem criar em quantas você quiser.

A principal diferença entre eles é que os clusters regionais criam três mestres, e os de várias zonas apenas um. Nos dois casos, o tráfego entre nodes nas zonas é cobrado.

No momento da criação do cluster, você escolhe se ele será de várias zonas ou regional. Você pode adicionar novas zonas a um cluster existente para torná-lo de várias zonas. No entanto, não é possível modificar um cluster atual para ser regional. Também não é possível transformar um cluster regional em não regional.

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. Além disso, o SLA do GKE garante um tempo de atividade mensal de 99,5% para os mestres de cluster do Kubernetes para clusters zonais e 99,95% para clusters regionais.

Desde 6 de junho de 2020, o GKE cobra uma taxa de gerenciamento de cluster de US $0, 10 por cluster por hora. Para ver detalhes, consulte apágina de preços.

Para saber mais sobre clusters regionais e de várias zonas, consulte a documentação do GKE.

Redes mestres autorizadas

Outra medida de segurança que pode ser aplicada no cluster é ativar redes mestres autorizadas. Esse recurso bloqueia o acesso ao servidor da API a partir dos intervalos CIDR que você especifica e garante que apenas as equipes na rede possam administrar o cluster.

Ao ativar esse recurso, lembre-se do seguinte:

  • Apenas 50 intervalos CIDR são permitidos.
  • Se você estiver usando um pipeline de CI/CD, verifique se as ferramentas de CI/CD têm acesso ao servidor de API do cluster ao permitir, incluindo na lista de permissões, os endereços IP ou o intervalo CIDR.

Também é possível usar esse recurso em conjunto com o Cloud Interconnect ou o Cloud VPN para permitir o acesso ao nó mestre somente dentro do seu data center particular.

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 privados. 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 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 abrir o acesso ao nó mestre fora da sua rede VPC, use clusters particulares com redes mestres autorizadas. Quando você ativa redes mestres autorizadas, o endpoint mestre 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 mestre pode ser usado por qualquer usuário ou processo externo à sua rede e proveniente de um intervalo CIDR ou endereço IP permitido. Os nós particulares não têm endereços IP externos e, por padrão, não têm acesso à Internet de saída. Isso também significa que, por padrão, o ambiente de execução do contêiner do cluster não pode extrair imagens de contêiner de um registro de contêiner externo, porque isso requer conectividade de saída. Considere hospedar suas imagens de contêiner no Container Registry e acessá-las usando o Acesso privado do Google. Como alternativa, use o Cloud NAT ou implante um gateway NAT para fornecer acesso de saída para os nós particulares.

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.

Como gerenciar identidades e acesso

Acesso no nível do projeto

Na seção anterior, foi possível vincular papéis do Cloud IAM a usuários no nível do projeto. Além de conceder papéis 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 Cloud IAM mostra o princípio do menor privilégio para um projeto dev configurado para que desenvolvedores possam desenvolver e testar os próximos recursos e correções de bugs, bem como o 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 meio de papéis do Cloud IAM entre os dois projetos:

Equipe Papel do Cloud IAM Projeto Permissões
Desenvolvedores container.developer dev Pode criar recursos do Kubernetes para os clusters existentes no projeto, sem permissão para criar ou excluir clusters.
Operações container.admin prod Acesso administrativo completo aos clusters e recursos do Kubernetes em execução no projeto.
Segurança container.viewer
security.admin
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 network.admin 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 proporcionar a scripts de automação ou frameworks de implantação a capacidade de agir por você. As implantações no projeto de produção e nos clusters precisam 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, garantindo que um desenvolvedor não use recursos demais no cluster. A próxima seção aborda a restrição à operação de certos namespaces por parte dos usuários.

Controle de acesso baseado em papéis (RBAC)

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 Cloud IAM pode fornecer aos usuários acesso a clusters completos 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 do 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.

O Grupos do Google para GKE (Beta) permite usar o Grupos com o RBAC do Kubernetes. Para usar esse recurso, configure os Grupos do Google do G Suite, crie um cluster com o recurso ativado e use RoleBindings para associar seus Grupos aos papéis que você quer vincular. Para mais informações, consulte Controle de acesso baseado em papel.

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 outro exemplo, há papéis do Cloud IAM no nível do projeto do Google Cloud que dão a determinados usuários acesso a todos os clusters em 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.

RoleBindings do Cloud IAM.

O Kubernetes inclui alguns papéis padrão, mas como administrador de cluster, é possível 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 (Beta) são armazenadas no Cloud Storage. Nesta seção, abordamos duas maneiras de compartilhar imagens. Uma delas é tornando-as públicas, a outra é compartilhando-as entre projetos.

Como tornar imagens públicas no Container Registry

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

Como acessar imagens em projetos no Container Registry

É possível compartilhar imagens de contêiner entre projetos, basta garantir que os nós do Kubernetes usem uma conta de serviço. A conta de serviço padrão associada ao projeto está no seguinte formato:

project-id-compute@developer.gserviceaccount.com

Esse identificador possibilita conceder a ele acesso de storage.viewer em projetos em que você quer usar o Container 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 outra conta de serviço com seus clusters, forneça a conta de serviço na criação do cluster ou do pool de nós usando a sinalização --service-account. Por exemplo, para usar a conta de serviço gke-sa no projeto my-project:

gcloud container clusters create west --service-account \
    gke-sa@my-project.google.com.iam.gserviceaccount.com

Para mais informações sobre como migrar do Container Registry para o Artifact Registry para as imagens de contêiner, consulte Como fazer a transição do Container Registry.

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

A propriedade imagePullPolicy determina se o Kubelet tentará extrair uma imagem enquanto estiver iniciando um pod. Considere uma configuração imagePullPolicy adequada para especificar 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 recuperará 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 webhooks de admissão dinâmica para aplicar políticas

Os webhooks 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 webhooks de admissão são uma ferramenta poderosa que pode ajudar a aplicar políticas personalizadas específicas à empresa nos clusters do GKE.

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

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

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

Por exemplo, é possível aplicar uma política de extração de imagens usando um webhook 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.

Outras considerações de implantação de imagem

É uma prática recomendada usar um registro de contêiner particular, como o Container Registry, para manter o conjunto selecionado de imagens da organização. Isso ajuda a reduzir o risco de introdução de vulnerabilidades no pipeline de implantação (e, por fim, nas cargas de trabalho do aplicativo). Se possível, ative a análise de contêiner, como a verificação de vulnerabilidades, para reduzir ainda mais os riscos de segurança.

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. Você também pode implantar aplicativos pré-compactados do Kubernetes a partir 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.

Além disso, use boas práticas de controle de imagens. Use boas convenções de inclusão de tag e use resumos em vez de tags quando aplicável.

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

Muitas vezes, as arquiteturas empresariais envolvem componentes de arquitetura que abrangem serviços em nuvem: serviços gerenciados por 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 é um recurso do GKE que permite que os serviços do GKE interajam com o ecossistema mais amplo do Google Cloud sem precisar armazenar credenciais de conta de serviço como chaves secretas do Kubernetes. Esse recurso permite mapear uma conta de serviço do Kubernetes para uma conta de serviço do Google Cloud com a ajuda de uma vinculação do Cloud IAM. Posteriormente, quando os pods são executados usando a conta de serviço do Kubernetes, eles podem assumir a identidade necessária para acessar o serviço 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.

Para mais informações sobre a identidade da carga de trabalho, consulte a documentação do GKE.

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 Container Registry pode verificar imagens que são enviadas para ele, procurando vulnerabilidades de segurança conhecidas em busca de imagens baseadas no Ubuntu, Alpine, Debian, CentOS e RedHat. Recomendamos que você aproveite esse recurso para verificar as imagens que planeja usar nos clusters do Kubernetes.

É possível ver as vulnerabilidades de uma imagem no console do Google Cloud ou executando o seguinte comando gcloud:

gcloud beta container images describe \
    hostname/project-id/image-id:tag  \
    --show-package-vulnerability

Substitua:

  • hostname: um dos seguintes locais de nome de host:
    • gcr.io, que hospeda atualmente as imagens nos Estados Unidos.
    • us.gcr.io, que hospeda a imagem nos Estados Unidos em um intervalo de armazenamento separado das imagens hospedadas por gcr.io.
    • eu.gcr.io, que hospeda as imagens na União Europeia.
    • asia.gcr.io, que hospeda as imagens na Ásia.
  • project-id: o ID do projeto que contém as imagens.
  • image-id: o ID da imagem com as vulnerabilidades que você quer ver.
  • tag: a tag de imagem que tem as informações que você quer receber.

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 Container 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 Container Registry são publicados. Use esses eventos para acionar versões ou implantações automatizadas. Para mais informações, consulte a documentação do Container 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, considere quais cargas de trabalho precisam desse nível elevado de segurança. Normalmente, bons candidatos são serviços baseados em imagens externas.

O comando gcloud a seguir mostra como criar um pool de nós com o GKE Sandbox ativado:

gcloud container node-pools create node-pool-name \
    --cluster=cluster \
    --image-type=cos_containerd \
    --sandbox type=gvisor \
    --enable-autoupgrade

Substitua:

  • node-pool-name: o nome do pool de modos a ser criado.
  • cluster: o cluster ao qual adicionar o pool de nós.

Para especificar quais pods de aplicativos são executados usando o GKE Sandbox, incorpore o gVisor na especificação do pod, como mostrado no exemplo a seguir:

apiVersion: v1
kind: Pod
metadata:
  name: sample-saas-app
  labels:
    app: saas-v1
spec:
  runtimeClassName: gvisor
  containers:
    - name: sample-node-app-v1
      image: [image]

Para mais informações sobre o GKE Sandbox, consulte GKE Sandbox: levar a defesa em profundidade para seus pods (em inglês) no blog do Google Cloud. Para mais informações sobre se o aplicativo é adequado para o GKE Sandbox, consulte a documentação do GKE.

Audit logging

O registro 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 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 de API do 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.

PodSecurityPolicies

Um vetor de ataque comum é implantar pods com privilégios encaminhados em uma tentativa de conseguir acesso a um cluster do Kubernetes. PodSecurityPolicies define um conjunto de regras na especificação do pod que descrevem o que um pod pode fazer. Você implementa um PodSecurityPolicy no Kubernetes como um recurso de controlador de admissão. É possível usá-lo para restringir o acesso a como os namespaces e os tipos de volume são usados e aos recursos subjacentes do SO.

Para criar um cluster do GKE com um PodSecurityPolicy ativado, use o comando a seguir. Substitua cluster-name pelo nome do cluster em que você está adicionando uma PodSecurityPolicy.

gcloud beta container clusters create cluster-name \
    --enable-pod-security-policy

O exemplo a seguir mostra um PodSecurityPollyy que restringe a capacidade de criar pods privilegiados.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: default-pod-security-policy
spec:
  privileged: false
  hostPID: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot

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. O primeiro é um cluster que usa intervalos de IP de alias para rotear o tráfego. Isso é chamado de cluster nativo de VPC. O segundo é um cluster que usa as rotas do Google Cloud. Isso é chamado de cluster com base 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.

Como se comunicar 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ó farão 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ó.

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 com " Nenhum", 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 do uso do ClusterIP estão listadas na documentação do Kubernetes.

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.

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. Para ter uma compreensão mais aprofundada sobre a rede do GKE, assista à palestra do Next 2017 no YouTube:

Serviços sem comando

Veja abaixo um exemplo da resposta DNS e do padrão de tráfego referente a um serviço sem comando. Os endereços IP do pod podem ser roteados por meio das tabelas de rotas da sub-rede do GCP 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

É possível usar a aplicação da política de rede do GKE para controlar a política no GKE, usar a comunicação políticas da rede do Kubernetes entre os pods e serviços do cluster. Para definir uma API de rede 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 são um tipo de defesa que aumenta a segurança das cargas de trabalho em execução no seu cluster. Por exemplo, crie 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.

As políticas de rede também podem ser usadas para isolar cargas de trabalho pertencentes a locatários diferentes. Por exemplo, forneça multilocação segura definindo um modelo de inquilino por 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.

Para saber mais sobre as políticas de rede, consulte a documentação do GKE.

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

Para se conectar aos serviços externamente ao cluster, mas dentro do espaço de endereço IP privado da rede do GCP, 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. Há três opções, descritas abaixo.

Domínios stub

No Kubernetes 1.6 e posterior, configure o serviço DNS interno do cluster (kube-dns) para encaminhar consultas DNS de um determinado domínio para um servidor DNS externo. Isso é útil quando você tem servidores DNS autorizados que devem ser consultados em relação a um domínio que os pods do Kubernetes precisarão aproveitar.

Serviços de nomes externos

Os 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. Isso precisa ser usado se você tiver apenas alguns registros dos quais quer fazer o mapeamento retroativo aos serviços DNS existentes.

Serviços sem seletores

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

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.
  • Adição de endereço IP ou listas de permissão de CIDR (listas de permissões) 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 a documentação do GKE.

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 deve ser 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 mais informações, consulte Istio no Google Kubernetes Engine.

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 command-line tool.

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

O Cloud Interconnect oferece várias opção para a conexão com data centers locais. Por não serem mutuamente excludentes, é possível combiná-las de acordo com a carga de trabalho e os requisitos:

  1. Internet para cargas de trabalho sem uso intenso de dados ou relacionadas à latência. 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.
  2. O peering direto para cargas de trabalho que exigem largura de banda dedicada é sensível à latência e precisa de acesso a todos os serviços do Google, incluindo o pacote completo de produtos do Google Cloud. O peering direto é uma conexão de camada 3, efetuada pela troca de rotas BGP e, portanto, requer um ASN registrado.
  3. Peering de operadora é o mesmo que peering direto, só que feito por meio de um provedor de serviços. É uma ótima opção quando você não tem um ASN registrado ou tem relações atuais com um provedor de serviços preferencial.
  4. O Cloud VPN é configurado na interconexão de camada 3 e nas opções de Internet (1, 2 e 3) caso a criptografia IPsec seja obrigatória ou caso você queira estender a rede privada à rede particular do Compute Engine.

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 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 que precisam estar em execução no aplicativo.

Em uma empresa em que os desenvolvedores trabalham em vários aplicativos, ocorrem erros e um desenvolvedor ou administrador pode executar acidentalmente um script que exclui pods ou implantações, em outras palavras, que exclui seus 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. Isso permite que você aproveite novos recursos que são implementados e verifique se o sistema operacional subjacente dos nós do cluster foi corrigido e atualizado.

Quando um upgrade for necessário, considere os seguintes tipos:

  • Atualizações de versão principais e secundárias do Kubernetes do cluster do GKE para os nós mestre e de trabalho.
  • Correções e upgrades do SO das máquinas virtuais (nós) que compõem o cluster.

Como fazer upgrade da versão do Kubernetes

Há duas opções para fazer upgrade dos nós mestres do GKE. A primeira é permitir que o Google Cloud faça upgrade automaticamente do mestre do cluster do GKE. A segunda é iniciar um upgrade manual quando uma versão mais recente estiver disponível.

É possível revisar as notificações no console que aparecem nos clusters do GKE quando os upgrades estão disponíveis. Recomendamos que você acione o upgrade da versão depois de revisar o conteúdo de lançamento e depois de testar seus aplicativos em um cluster do sandbox que está em execução na versão em que você quer fazer upgrade.

Quando o nó mestre de um cluster zonal está passando por um upgrade, o plano de controle fica indisponível. Isso significa que não é possível interagir com o servidor de API para adicionar ou remover recursos do cluster. Se você não puder arcar com o tempo de inatividade para fazer upgrade de um nó mestre no cluster zonal, torne o nó mestre altamente disponível com a implantação de clusters regionais do GKE. Com essa abordagem, é possível ter vários nós mestres distribuídos entre as zonas. Quando um nó mestre está sendo atualizado, todas as solicitações de plano de controle para o servidor da API são roteadas para o outro nó mestre.

Assim como os nós mestres, você tem duas opções para fazer upgrade dos nós de trabalho do GKE para a mesma versão que o nó mestre do cluster:

  • É possível fazer com que o GKE gerencie os upgrades de nós de trabalho para você. Para isso, ative o upgrade automático de nós para os pools de nós no cluster do GKE.
  • É possível fazer upgrade manual dos nós de trabalho do GKE. Quando um upgrade está disponível, o console do GKE mostra um alerta. Quando você vir esse alerta, poderá aplicar o upgrade aos nós de trabalho do GKE.

Em ambos os casos, quando um upgrade é aplicado, o GKE aplica uma atualização gradual aos nós de trabalho. 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ó.

O processo de reparo do nó gerenciado envolve a diminuição e a recriação do nó. Se vários nós no cluster do GKE precisarem ser reparados ao mesmo tempo, o Google Cloud determina internamente quantos nós podem ser reparados em paralelo.

Se você criar clusters no Console do Google Cloud, o recurso de reparo automático será ativado automaticamente. Para os clusters do GKE que você cria usando a ferramenta gcloud command-line tool, é possível ativar explicitamente o reparo automático incluindo a sinalização --enable-autorepair no comando de criação do cluster.

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.

Uma combinação de fatores influencia a maneira como o GKE decide reduzir. Se um nó for usado menos de 50% pelos pods em execução e se os pods em execução puderem ser programados em outros nós com 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.

Escalonamento automático horizontal de pods (HPA)

O Kubernetes permite criar um escalonador automático de pod horizontal (HPA, na sigla em inglês), que permite configurar como as implantações do Kubernetes ou ReplicaSets precisam ser escalonadas e em quais métricas a decisão de escalonamento deve ser baseada. Por padrão, o controlador HPA baseia as decisões de escalonamento automático na utilização da CPU. No entanto, o controlador HPA também pode calcular como os pods devem ser escalonados com base em métricas personalizadas, como uma contagem de solicitações HTTP. Para que um HPA responda a métricas personalizadas, geralmente é necessária uma instrumentação de monitoramento adicional.

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

Escalonamento automático vertical de pods (VPA)

O recurso de escalonamento automático do pod vertical (VPA, na sigla em inglês) 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 VPA ajusta as alocações de recursos que são feitas para contêineres no cluster. A VPA permite otimizar a utilização de recursos para clusters 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 VPA 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 VPA remove o pod. Para mais informações, consulte a documentação do GKE e do Kubernetes (links em inglês).

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

A seguir

  • Saiba mais sobre as práticas recomendadas para criar e operar contêineres.
  • Saiba mais sobre como autenticar usuários finais no Cloud Run no GKE usando o Istio neste tutorial.
  • Teste outros recursos do Google Cloud. Veja nossos tutoriais.