Conceitos

A seção de Conceitos irá te ajudar a aprender mais sobre as partes do ecossistema Kubernetes e as abstrações que o Kubernetes usa para representar seu cluster.

Ela irá lhe ajudar a obter um entendimento mais profundo sobre como o Kubernetes funciona.

1 - Pods

Pods são as menores unidades computacionais implantáveis que você pode criar e gerenciar no Kubernetes.

Um Pod é um grupo de um ou mais contêineres, com recursos de armazenamento e rede compartilhados e uma especificação de como executar os contêineres. O conteúdo de um Pod é sempre colocalizado e coalocado, e executado em um contexto compartilhado. Um Pod modela um "host lógico" específico da aplicação: ele contém um ou mais contêineres de aplicação que são relativamente fortemente acoplados. Em contextos fora da nuvem, aplicações executadas na mesma máquina física ou virtual são análogas a aplicações em nuvem executadas no mesmo host lógico.

Além dos contêineres de aplicação, um Pod pode conter contêineres de inicialização que são executados durante a inicialização do Pod. Você também pode injetar contêineres efêmeros para depurar um Pod em execução.

O que é um Pod?

O contexto compartilhado de um Pod é um conjunto de namespaces do Linux, cgroups e potencialmente outras facetas de isolamento - as mesmas coisas que isolam um contêiner. Dentro do contexto de um Pod, as aplicações individuais podem ter sub-isolamentos adicionais aplicados.

Um Pod é semelhante a um conjunto de contêineres com namespaces compartilhados e volumes de sistema de arquivos compartilhados.

Pods em um cluster Kubernetes são usados de duas maneiras principais:

• Pods que executam um único contêiner. O modelo "um-contêiner-por-Pod" é o caso de uso mais comum do Kubernetes; neste caso, você pode pensar em um Pod como um invólucro em torno de um único contêiner; o Kubernetes gerencia Pods ao invés de gerenciar os contêineres diretamente.

• Pods que executam múltiplos contêineres que precisam trabalhar juntos. Um Pod pode encapsular uma aplicação composta por múltiplos contêineres colocalizados que são fortemente acoplados e precisam compartilhar recursos. Esses contêineres colocalizados formam uma única unidade coesa.

  Agrupar múltiplos contêineres colocalizados e cogerenciados em um único Pod é um caso de uso relativamente avançado. Você deve usar esse padrão apenas em instâncias específicas nas quais seus contêineres são fortemente acoplados.

  Você não precisa executar múltiplos contêineres para fornecer replicação (para resiliência ou capacidade); se você precisa de múltiplas réplicas, consulte Gerenciamento de carga de trabalho.

Usando Pods

O seguinte é um exemplo de um Pod que consiste em um contêiner executando a imagem nginx:1.14.2.

pods/simple-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Para criar o Pod mostrado acima, execute o seguinte comando:

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

Pods geralmente não são criados diretamente e são criados usando recursos de carga de trabalho. Consulte Trabalhando com Pods para mais informações sobre como os Pods são usados com recursos de carga de trabalho.

Recursos de carga de trabalho para gerenciar pods

Normalmente você não precisa criar Pods diretamente, nem mesmo Pods únicos. Em vez disso, crie-os usando recursos de carga de trabalho como Deployment ou Job. Se seus Pods precisam rastrear estado, considere o recurso StatefulSet.

Cada Pod é destinado a executar uma única instância de uma determinada aplicação. Se você deseja escalar sua aplicação horizontalmente (para fornecer mais recursos gerais executando mais instâncias), você deve usar múltiplos Pods, um para cada instância. No Kubernetes, isso é tipicamente referido como replicação. Pods replicados são geralmente criados e gerenciados como um grupo por um recurso de carga de trabalho e seu controlador.

Consulte Pods e controladores para mais informações sobre como o Kubernetes usa recursos de carga de trabalho, e seus controladores, para implementar escalonamento de aplicação e autorrecuperação.

Pods nativamente fornecem dois tipos de recursos compartilhados para seus contêineres constituintes: rede e armazenamento.

Trabalhando com Pods

Você raramente criará Pods individuais diretamente no Kubernetes—nem mesmo Pods únicos. Isso ocorre porque os Pods são projetados como entidades relativamente efêmeras e descartáveis. Quando um Pod é criado (diretamente por você, ou indiretamente por um controlador), o novo Pod é alocado para ser executado em um Nó no seu cluster. O Pod permanece naquele nó até que o Pod termine a execução, o objeto Pod seja excluído, o Pod seja removido por falta de recursos, ou o nó falhe.

O nome de um Pod deve ser um valor de subdomínio DNS válido, mas isso pode produzir resultados inesperados para o hostname do Pod. Para melhor compatibilidade, o nome deve seguir as regras mais restritivas para um rótulo DNS.

SO do Pod

Você deve definir o campo .spec.os.name como windows ou linux para indicar o sistema operacional no qual você deseja que o pod seja executado. Esses dois são os únicos sistemas operacionais suportados até o momento pelo Kubernetes. No futuro, esta lista pode ser expandida.

No Kubernetes v1.35, o valor de .spec.os.name não afeta como o kube-scheduler escolhe um nó para o Pod ser executado. Em qualquer cluster onde há mais de um sistema operacional para executar nós, você deve definir o rótulo kubernetes.io/os corretamente em cada nó, e definir pods com um nodeSelector baseado no rótulo do sistema operacional. O kube-scheduler aloca seu pod para um nó com base em outros critérios e pode ou não ter sucesso em escolher uma alocação de nó adequada onde o sistema operacional do nó seja adequado para os contêineres naquele Pod. Os padrões de segurança de Pod também usam este campo para evitar impor políticas que não sejam relevantes para o sistema operacional.

Pods e controladores

Você pode usar recursos de carga de trabalho para criar e gerenciar múltiplos Pods para você. Um controlador para o recurso lida com replicação e implantação e recuperação automática em caso de falha do Pod. Por exemplo, se um nó falha, um controlador percebe que os Pods naquele nó pararam de funcionar e cria um Pod substituto. O alocador coloca o Pod substituto em um nó íntegro.

Aqui estão alguns exemplos de recursos de carga de trabalho que gerenciam um ou mais Pods:

• Deployment
• StatefulSet
• DaemonSet

Modelos de Pod

Controladores para recursos de carga de trabalho criam Pods a partir de um modelo de Pod e gerenciam esses Pods em seu nome.

PodTemplates são especificações para criar Pods, e estão incluídos em recursos de carga de trabalho como Deployments, Jobs, e DaemonSets.

Cada controlador para um recurso de carga de trabalho usa o PodTemplate dentro do objeto de carga de trabalho para criar Pods reais. O PodTemplate é parte do estado desejado de qualquer recurso de carga de trabalho que você usou para executar sua aplicação.

Quando você cria um Pod, você pode incluir variáveis de ambiente no modelo de Pod para os contêineres que são executados no Pod.

O exemplo abaixo é um manifesto para um Job simples com um template que inicia um contêiner. O contêiner naquele Pod imprime uma mensagem e então pausa.

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # Este é o modelo de Pod
    spec:
      containers:
      - name: hello
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # O modelo de Pod termina aqui

Modificar o modelo de Pod ou alternar para um novo modelo de Pod não tem efeito direto nos Pods que já existem. Se você alterar o modelo de Pod para um recurso de carga de trabalho, esse recurso precisa criar Pods substitutos que usem o modelo atualizado.

Por exemplo, o controlador StatefulSet garante que os Pods em execução correspondam ao modelo de Pod atual para cada objeto StatefulSet. Se você editar o StatefulSet para alterar seu modelo de Pod, o StatefulSet começa a criar novos Pods baseados no modelo atualizado. Eventualmente, todos os Pods antigos são substituídos por novos Pods, e a atualização é concluída.

Cada recurso de carga de trabalho implementa suas próprias regras para lidar com alterações no modelo de Pod. Se você quiser ler mais sobre StatefulSet especificamente, leia Estratégia de atualização no tutorial Básico de StatefulSet.

Nos nós, o kubelet não observa ou gerencia diretamente nenhum dos detalhes relacionados a modelos de Pod e atualizações; esses detalhes são abstraídos. Essa abstração e separação de responsabilidades simplifica a semântica do sistema, e torna viável estender o comportamento do cluster sem alterar código existente.

Atualização e substituição de Pod

Como mencionado na seção anterior, quando o modelo de Pod para um recurso de carga de trabalho é alterado, o controlador cria novos Pods baseados no modelo atualizado em vez de atualizar ou corrigir os Pods existentes.

O Kubernetes não impede que você gerencie Pods diretamente. É possível atualizar alguns campos de um Pod em execução, diretamente na configuração aplicada. No entanto, operações de atualização de Pod como patch e replace, têm algumas limitações:

• A maioria dos metadados sobre um Pod é imutável. Por exemplo, você não pode alterar os campos namespace, name, uid, ou creationTimestamp.

• Se o metadata.deletionTimestamp estiver definido, nenhuma nova entrada pode ser adicionada à lista metadata.finalizers.

• Atualizações de Pod não podem alterar campos além de spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds, spec.terminationGracePeriodSeconds, spec.tolerations ou spec.schedulingGates. Para spec.tolerations, você só pode adicionar novas entradas.

• Ao atualizar o campo spec.activeDeadlineSeconds, dois tipos de atualizações são permitidos:

  1. definir o campo não atribuído para um número positivo;
  2. atualizar o campo de um número positivo para um número menor, não negativo.

Subrecursos de Pod

As regras de atualização acima se aplicam a atualizações regulares de Pod, mas outros campos de Pod podem ser atualizados através de subrecursos.

• Resize: O subrecurso resize permite que recursos de contêiner (spec.containers[*].resources) sejam atualizados. Consulte Redimensionar Recursos de Contêiner para mais detalhes.
• Contêineres Efêmeros: O subrecurso ephemeralContainers permite que contêineres efêmeros sejam adicionados a um Pod. Consulte Contêineres Efêmeros para mais detalhes.
• Status: O subrecurso status permite que o status do Pod seja atualizado. Isso é tipicamente usado apenas pelo Kubelet e outros controladores do sistema.
• Binding: O subrecurso binding permite definir o spec.nodeName do Pod via uma requisição Binding. Isso é tipicamente usado apenas pelo escalonador.

Geração de Pod

• O campo metadata.generation é único. Ele será automaticamente definido pelo sistema de forma que novos pods tenham um metadata.generation de 1, e cada atualização em campos mutáveis na especificação do pod incrementará o metadata.generation em 1.

• observedGeneration é um campo que é capturado na seção status do objeto Pod. Se o feature gate PodObservedGenerationTracking estiver definido, o Kubelet definirá status.observedGeneration para rastrear o estado do Pod ao status atual do Pod. O status.observedGeneration do Pod refletirá a metadata.generation do Pod no ponto em que o status do Pod está sendo reportado.

Diferentes campos de status podem estar associados à metadata.generation do ciclo de sincronização atual, ou com a metadata.generation do ciclo de sincronização anterior. A distinção chave é se uma mudança na spec é refletida diretamente no status ou é um resultado indireto de um processo em execução.

Atualizações Diretas de Status

Para campos de status onde a especificação alocada é diretamente refletida, o observedGeneration será associado à metadata.generation atual (Geração N).

Este comportamento se aplica a:

• Status de Redimensionamento: O status de uma operação de redimensionamento de recurso.
• Recursos Alocados: Os recursos alocados ao Pod após um redimensionamento.
• Contêineres Efêmeros: Quando um novo contêiner efêmero é adicionado, e ele está no estado Waiting.

Atualizações Indiretas de Status

Para campos de status que são um resultado indireto da execução da especificação, o observedGeneration será associado à metadata.generation do ciclo de sincronização anterior (Geração N-1).

Este comportamento se aplica a:

• Imagem do Contêiner: O ContainerStatus.ImageID reflete a imagem da geração anterior até que a nova imagem seja baixada e o contêiner seja atualizado.
• Recursos atuais: Durante um redimensionamento em andamento, os recursos atuais em uso ainda pertencem à requisição da geração anterior.
• Estado do contêiner: Durante um redimensionamento em andamento, com política de reinicialização necessária reflete a requisição da geração anterior.
• activeDeadlineSeconds & terminationGracePeriodSeconds & deletionTimestamp: Os efeitos desses campos no status do Pod são resultado da especificação observada anteriormente.

Compartilhamento de recursos e comunicação

Pods permitem o compartilhamento de dados e comunicação entre seus contêineres constituintes.

Armazenamento em Pods

Um Pod pode especificar um conjunto de volumes de armazenamento compartilhados. Todos os contêineres no Pod podem acessar os volumes compartilhados, permitindo que esses contêineres compartilhem dados. Volumes também permitem que dados persistentes em um Pod sobrevivam caso um dos contêineres precise ser reiniciado. Consulte Armazenamento para mais informações sobre como o Kubernetes implementa armazenamento compartilhado e o torna disponível para Pods.

Rede do Pod

Cada Pod recebe um endereço IP único para cada família de endereços. Cada contêiner em um Pod compartilha o namespace de rede, incluindo o endereço IP e portas de rede. Dentro de um Pod (e somente então), os contêineres que pertencem ao Pod podem se comunicar uns com os outros usando localhost. Quando contêineres em um Pod se comunicam com entidades fora do Pod, eles devem coordenar como usam os recursos de rede compartilhados (como portas). Dentro de um Pod, contêineres compartilham um endereço IP e espaço de portas, e podem encontrar uns aos outros via localhost. Os contêineres em um Pod também podem se comunicar uns com os outros usando comunicações interprocessos padrão como semáforos SystemV ou memória compartilhada POSIX. Contêineres em Pods diferentes têm endereços IP distintos e não podem se comunicar por IPC em nível de sistema operacional sem configuração especial. Contêineres que desejam interagir com um contêiner executando em um Pod diferente podem usar rede IP para se comunicar.

Contêineres dentro do Pod veem o nome do host do sistema como sendo o mesmo que o name configurado para o Pod. Mais informações sobre isso na seção de rede.

Configurações de segurança de Pod

Para definir restrições de segurança em Pods e contêineres, você usa o campo securityContext na especificação do Pod. Este campo oferece controle granular sobre o que um Pod ou contêineres individuais podem fazer. Por exemplo:

• Remover capacidades (capabilities) específicas do Linux para evitar o impacto de uma CVE.
• Forçar todos os processos no Pod a serem executados como usuário não-root ou como um usuário específico ou ID de grupo.
• Definir um perfil seccomp específico.
• Definir opções de segurança do Windows, como se os contêineres são executados como HostProcess.

• Para aprender sobre restrições de segurança em nível de kernel que você pode usar, consulte Restrições de segurança do kernel Linux para Pods e Contêineres.
• Para saber mais sobre o contexto de segurança do Pod, consulte Configurar um Contexto de Segurança para um Pod ou Contêiner.

Pods Estáticos

Pods Estáticos são gerenciados diretamente pelo daemon kubelet em um nó específico, sem que o servidor de API os observe. Enquanto a maioria dos Pods são gerenciados pela camada de gerenciamento (por exemplo, um Deployment), para Pods estáticos, o kubelet supervisiona diretamente cada Pod estático (e o reinicia se falhar).

Pods estáticos estão sempre vinculados a um Kubelet em um nó específico. O uso principal para Pods estáticos é executar uma camada de gerenciamento auto-hospedada: em outras palavras, usar o kubelet para supervisionar os componentes da camada de gerenciamento individuais.

O kubelet tenta automaticamente criar um Pod espelho no servidor de API do Kubernetes para cada Pod estático. Isso significa que os Pods em execução em um nó são visíveis no servidor de API, mas não podem ser controlados de lá. Consulte o guia Criar Pods estáticos para mais informações.

Pods com múltiplos contêineres

Pods são projetados para suportar múltiplos processos cooperantes (como contêineres) que formam uma unidade coesa de serviço. Os contêineres em um Pod são automaticamente colocalizados e coalocados na mesma máquina física ou virtual no cluster. Os contêineres podem compartilhar recursos e dependências, comunicar-se uns com os outros, e coordenar quando e como são encerrados.

Pods em um cluster Kubernetes são usados de duas maneiras principais:

• Pods que executam um único contêiner. O modelo "um-contêiner-por-Pod" é o caso de uso mais comum do Kubernetes; neste caso, você pode pensar em um Pod como um invólucro em torno de um único contêiner; o Kubernetes gerencia Pods ao invés de gerenciar os contêineres diretamente.
• Pods que executam múltiplos contêineres que precisam trabalhar juntos. Um Pod pode encapsular uma aplicação composta por múltiplos contêineres colocalizados que são fortemente acoplados e precisam compartilhar recursos. Esses contêineres colocalizados formam uma única unidade coesa de serviço—por exemplo, um contêiner servindo dados armazenados em um volume compartilhado para o público, enquanto um contêiner sidecar separado atualiza ou renova esses arquivos. O Pod envolve esses contêineres, recursos de armazenamento e uma identidade de rede efêmera juntos como uma única unidade.

Por exemplo, você pode ter um contêiner que atua como um servidor web para arquivos em um volume compartilhado, e um contêiner sidecar separado que atualiza esses arquivos de uma fonte remota, como no diagrama a seguir:

Alguns Pods têm contêineres de inicialização assim como contêineres de aplicação. Por padrão, contêineres de inicialização são executados e concluídos antes que os contêineres de aplicação sejam iniciados.

Você também pode ter contêineres sidecar que fornecem serviços auxiliares ao Pod de aplicação principal (por exemplo: uma malha de serviços).

Habilitado por padrão, o feature gate SidecarContainers permite que você especifique restartPolicy: Always para contêineres de inicialização. Definir a política de reinicialização Always garante que os contêineres onde você a define sejam tratados como sidecars que são mantidos em execução durante todo o tempo de vida do Pod. Contêineres que você define explicitamente como contêineres sidecar iniciam antes do Pod de aplicação principal e permanecem em execução até que o Pod seja encerrado.

Verificações de contêiner

Uma verificação é um diagnóstico realizado periodicamente pelo kubelet em um contêiner. Para realizar um diagnóstico, o kubelet pode invocar diferentes ações:

• ExecAction (realizada com a ajuda do agente de execução de contêiner)
• TCPSocketAction (verificada diretamente pelo kubelet)
• HTTPGetAction (verificada diretamente pelo kubelet)

Você pode ler mais sobre verificações na documentação de Ciclo de Vida do Pod.

Próximos passos

• Aprenda sobre o ciclo de vida de um Pod.
• Aprenda sobre RuntimeClass e como você pode usá-lo para configurar diferentes Pods com diferentes configurações de agente de execução de contêiner.
• Leia sobre PodDisruptionBudget e como você pode usá-lo para gerenciar a disponibilidade da aplicação durante interrupções.
• Pod é um recurso de nível superior na API REST do Kubernetes. A definição do objeto Pod descreve o objeto em detalhes.
• The Distributed System Toolkit: Patterns for Composite Containers explica layouts comuns para Pods com mais de um contêiner.
• Leia sobre restrições de distribuição de topologia de Pod.

Para entender o contexto de por que o Kubernetes envolve uma API de Pod comum em outros recursos (como StatefulSets ou Deployments), você pode ler sobre trabalhos anteriores, incluindo:

• Aurora
• Borg
• Marathon
• Omega
• Tupperware.

1.1 - Interrupções

Este guia é destinado a proprietários de aplicações que desejam construir aplicações altamente disponíveis e, portanto, precisam entender quais tipos de interrupções podem acontecer com os Pods.

Também é destinado a administradores de cluster que desejam executar ações automatizadas no cluster, como atualização e escalonamento automático de clusters.

Interrupções voluntárias e involuntárias

Os Pods não desaparecem até que alguém (uma pessoa ou um controlador) os destrua, ou ocorra um erro inevitável de hardware ou software do sistema.

Chamamos esses casos inevitáveis de interrupções involuntárias para uma aplicação. Exemplos incluem:

• uma falha de hardware da máquina física que sustenta o nó.
• administrador do cluster exclui a VM (instância) por engano.
• falha do provedor de nuvem ou do hipervisor faz a VM desaparecer.
• um kernel panic.
• o nó desaparece do cluster devido a uma partição de rede do cluster.
• remoção de um Pod devido ao nó estar sem recursos.

Exceto pela condição de falta de recursos, todas essas condições devem ser familiares para a maioria dos usuários; elas não são específicas do Kubernetes.

Chamamos os outros casos de interrupções voluntárias. Estas incluem tanto ações iniciadas pelo proprietário da aplicação quanto aquelas iniciadas por um Administrador de Cluster. Ações típicas do proprietário da aplicação incluem:

• excluir o deployment ou outro controlador que gerencia o Pod.
• atualizar o template do Pod de um deployment causando uma reinicialização.
• excluir diretamente um Pod (por exemplo, por acidente).

As ações do administrador de cluster incluem:

• Drenar um nó para reparo ou atualização.
• Drenar um nó de um cluster para reduzir o cluster (saiba mais sobre Escalonamento Automático de Nós).
• Remover um Pod de um nó para permitir que algo mais caiba naquele nó.

Essas ações podem ser executadas diretamente pelo administrador do cluster, ou por automação executada pelo administrador do cluster, ou pelo seu provedor de hospedagem do cluster.

Consulte seu administrador de cluster ou consulte a documentação do seu provedor de nuvem ou distribuição para determinar se alguma fonte de interrupções voluntárias está habilitada para o seu cluster. Se nenhuma estiver habilitada, você pode pular a criação de Orçamentos de Interrupção de Pods.

Lidando com interrupções

Aqui estão algumas maneiras de mitigar interrupções involuntárias:

• Certifique-se de que seu Pod solicita os recursos de que necessita.
• Replique sua aplicação se precisar de maior disponibilidade. (Saiba mais sobre executar aplicações replicadas sem estado e com estado).
• Para uma disponibilidade ainda maior ao executar aplicações replicadas, distribua as aplicações entre racks (usando antiafinidade) ou entre zonas (se estiver usando um cluster multizona).

A frequência de interrupções voluntárias varia. Em um cluster Kubernetes básico, não há interrupções voluntárias automatizadas (apenas aquelas acionadas pelo usuário). No entanto, seu administrador de cluster ou provedor de hospedagem pode executar alguns serviços adicionais que causam interrupções voluntárias. Por exemplo, atualizar o software do nó pode causar interrupções voluntárias. Além disso, algumas implementações de escalonamento automático de cluster (nó) podem causar interrupções voluntárias para desfragmentar e compactar nós. Seu administrador de cluster ou provedor de hospedagem deve ter documentado qual nível de interrupções voluntárias, se houver, esperar. Certas opções de configuração, como usar PriorityClasses na especificação do seu Pod também podem causar interrupções voluntárias (e involuntárias).

Orçamentos de Interrupção de Pods

O Kubernetes oferece funcionalidades para ajudá-lo a executar aplicações altamente disponíveis mesmo quando você introduz interrupções voluntárias frequentes.

Como proprietário de uma aplicação, você pode criar um PodDisruptionBudget (PDB) para cada aplicação. Um PDB limita o número de Pods de uma aplicação replicada que estão inativos simultaneamente devido a interrupções voluntárias. Por exemplo, uma aplicação baseada em quórum gostaria de garantir que o número de réplicas em execução nunca seja reduzido abaixo do número necessário para um quórum. Um front-end web pode querer garantir que o número de réplicas atendendo a carga nunca caia abaixo de uma certa porcentagem do total.

Administradores de cluster e provedores de hospedagem devem usar ferramentas que respeitem PodDisruptionBudgets através do uso da API de Remoção em vez de excluir diretamente Pods ou Deployments.

Por exemplo, o subcomando kubectl drain permite marcar um nó como sendo retirado de serviço. Quando você executa kubectl drain, a ferramenta tenta remover todos os Pods do nó que você está retirando de serviço. A solicitação de remoção que o kubectl envia em seu nome pode ser temporariamente rejeitada, então a ferramenta repete periodicamente todas as solicitações com falha até que todos os Pods no nó de destino sejam encerrados, ou até que um tempo limite configurável seja atingido.

Um PDB especifica o número de réplicas que uma aplicação pode tolerar ter, em relação a quantas ela pretende ter. Por exemplo, um Deployment que tem .spec.replicas: 5 deve ter 5 Pods a qualquer momento. Se seu PDB permite que existam 4 por vez, então a API de Remoção permitirá a interrupção voluntária de um (mas não dois) Pods por vez.

O grupo de Pods que compõem a aplicação é especificado usando um seletor de rótulos, o mesmo usado pelo controlador da aplicação (deployment, stateful-set, etc.).

O número "pretendido" de Pods é calculado a partir do .spec.replicas do recurso de carga de trabalho que está gerenciando esses Pods. A camada de gerenciamento descobre o recurso de carga de trabalho proprietário examinando o .metadata.ownerReferences do Pod.

Interrupções involuntárias não podem ser evitadas por PDBs; no entanto, elas contam contra o orçamento.

Pods que são excluídos ou indisponíveis devido a uma atualização gradual de uma aplicação contam contra o orçamento de interrupção, mas recursos de carga de trabalho (como Deployment e StatefulSet) não são limitados por PDBs ao realizar atualizações graduais. Em vez disso, o tratamento de falhas durante atualizações de aplicações é configurado na especificação do recurso de carga de trabalho específico.

É recomendado definir AlwaysAllow como Política de Remoção de Pods Não Íntegros em seus PodDisruptionBudgets para suportar a remoção de aplicações com comportamento inadequado durante a drenagem de um nó. O comportamento padrão é aguardar que os Pods da aplicação se tornem íntegros antes que a drenagem possa prosseguir.

Quando um Pod é removido usando a API de remoção, ele é controladamente encerrado, respeitando a configuração terminationGracePeriodSeconds em sua PodSpec.

Exemplo de PodDisruptionBudget

Considere um cluster com 3 nós, node-1 a node-3. O cluster está executando várias aplicações. Uma delas tem 3 réplicas inicialmente chamadas pod-a, pod-b e pod-c. Outro Pod não relacionado, sem um PDB, chamado pod-x, também é mostrado. Inicialmente, os Pods estão distribuídos da seguinte forma:

Todos os 3 Pods fazem parte de um Deployment, e coletivamente têm um PDB que exige que pelo menos 2 dos 3 Pods estejam disponíveis o tempo todo.

Por exemplo, suponha que o administrador do cluster queira reiniciar em uma nova versão do kernel para corrigir um bug no kernel. O administrador do cluster primeiro tenta drenar node-1 usando o comando kubectl drain. Essa ferramenta tenta remover pod-a e pod-x. Isso é bem-sucedido imediatamente. Ambos os Pods entram no estado terminating ao mesmo tempo. Isso coloca o cluster neste estado:

O Deployment percebe que um dos Pods está sendo encerrado, então cria uma substituição chamada pod-d. Como node-1 está isolado, ele é alocado em outro nó. Algo também criou pod-y como substituição para pod-x.

(Nota: para um StatefulSet, pod-a, que seria chamado de algo como pod-0, precisaria ser totalmente encerrado antes que sua substituição, que também é chamada de pod-0 mas tem um UID diferente, pudesse ser criada. Caso contrário, o exemplo também se aplica a um StatefulSet.)

Agora o cluster está neste estado:

Em algum momento, os Pods são encerrados, e o cluster fica assim:

Neste ponto, se um administrador de cluster impaciente tentar drenar node-2 ou node-3, o comando drain será bloqueado, porque há apenas 2 Pods disponíveis para o Deployment, e seu PDB exige pelo menos 2. Depois de algum tempo, pod-d se torna disponível.

O estado do cluster agora fica assim:

Agora, o administrador do cluster tenta drenar node-2. O comando drain tentará remover os dois Pods em alguma ordem, digamos pod-b primeiro e depois pod-d. Ele terá sucesso ao remover pod-b. Mas, quando tentar remover pod-d, será recusado porque isso deixaria apenas um Pod disponível para o Deployment.

O Deployment cria uma substituição para pod-b chamada pod-e. Como não há recursos suficientes no cluster para alocar pod-e, a drenagem será bloqueada novamente. O cluster pode acabar neste estado:

Neste ponto, o administrador do cluster precisa adicionar um nó de volta ao cluster para prosseguir com a atualização.

Você pode ver como o Kubernetes varia a taxa na qual as interrupções podem acontecer, de acordo com:

• quantas réplicas uma aplicação precisa
• quanto tempo leva para encerrar controladamente uma instância
• quanto tempo leva para uma nova instância iniciar
• o tipo de controlador
• a capacidade de recursos do cluster

Condições de interrupção de Pods

Uma condição dedicada DisruptionTarget do Pod condition é adicionada para indicar que o Pod está prestes a ser excluído devido a uma interrupção. O campo reason da condição adicionalmente indica um dos seguintes motivos para o encerramento do Pod:

PreemptionByScheduler

O Pod deve sofrer preempção por um escalonador para acomodar um novo Pod com uma prioridade mais alta. Para mais informações, consulte Preempção por prioridade de Pod.

DeletionByTaintManager

O Pod deve ser excluído pelo Taint Manager (que faz parte do controlador de ciclo de vida do nó dentro do kube-controller-manager) devido a um taint NoExecute que o Pod não tolera; veja remoções baseadas em taint.

EvictionByEvictionAPI

O Pod foi marcado para remoção usando a API do Kubernetes.

DeletionByPodGC

O Pod, que está vinculado a um nó que não existe mais, deve ser excluído pela coleta de lixo de Pod.

TerminationByKubelet

O Pod foi encerrado pelo kubelet, devido a remoção por pressão no nó, o desligamento controlado do nó, ou substituição para Pods críticos do sistema.

Em todos os outros cenários de interrupção, como remoção devido a exceder limites de contêiner do Pod, os Pods não recebem a condição DisruptionTarget porque as interrupções provavelmente foram causadas pelo Pod e ocorreriam novamente em uma nova tentativa.

Juntamente com a limpeza dos Pods, o coletor de lixo de Pods (PodGC) também os marcará como falhados se estiverem em uma fase não terminal (veja também coleta de lixo de Pod).

Ao usar uma tarefa (ou CronJob), você pode querer usar essas condições de interrupção de Pod como parte da política de falha de Pod da sua tarefa.

Separando os Papéis de Proprietário do Cluster e Proprietário da Aplicação

Frequentemente, é útil pensar no Administrator do cluster e no Proprietário da aplicação como papéis separados com conhecimento limitado um do outro. Esta separação de responsabilidades pode fazer sentido nestes cenários:

• quando há muitas equipes de aplicação compartilhando um cluster Kubernetes, e há uma especialização natural de papéis.
• quando ferramentas ou serviços de terceiros são usados para automatizar o gerenciamento do cluster.

Os Orçamentos de Interrupção de Pods apoiam esta separação de papéis fornecendo uma interface entre os papéis.

Se você não tem essa separação de responsabilidades em sua organização, você pode não precisar usar Orçamentos de Interrupção de Pods.

Como Realizar Ações Disruptivas no seu Cluster

Se você é um Administrador de cluster e precisa realizar uma ação disruptiva em todos os nós do seu cluster, como uma atualização de nó ou software do sistema, aqui estão algumas opções:

• Aceitar tempo de inatividade durante a atualização.
• Fazer failover para outro cluster de réplica completo.
  • Sem tempo de inatividade, mas pode ser custoso tanto pelos nós duplicados quanto pelo esforço humano para orquestrar a troca.
• Escrever aplicações tolerantes a interrupções e usar PDBs.
  • Sem tempo de inatividade.
  • Duplicação mínima de recursos.
  • Permite mais automação da administração do cluster.
  • Escrever aplicações tolerantes a interrupções é complicado, mas o trabalho para tolerar interrupções voluntárias se sobrepõe em grande parte ao trabalho de suportar escalonamento automático e tolerar interrupções involuntárias.

Próximos passos

• Siga os passos para proteger sua aplicação configurando um Orçamento de Interrupção de Pods.

• Saiba mais sobre drenar nós

• Saiba mais sobre atualizar um Deployment incluindo passos para manter sua disponibilidade durante a implementação.

2 - Controladores

2.1 - ReplicaSet

O propósito de um ReplicaSet é gerenciar um conjunto de réplicas de Pods em execução a qualquer momento. Por isso, é geralmente utilizado para garantir a disponibilidade de um certo número de Pods idênticos.

Como um ReplicaSet funciona

Um ReplicaSet é definido por campos, incluindo um seletor que identifica quais Pods podem ser adquiridos, um número de réplicas indicando quantos Pods devem ser mantidos, e um pod template especificando as definições para novos Pods que devem ser criados para atender ao número de réplicas estipuladas. Um ReplicaSet cumpre seu propósito criando e deletando Pods conforme for preciso para atingir o número desejado. Quando um ReplicaSet precisa criar novos Pods, ele usa o seu podTemplate.

Um ReplicaSet é conectado ao seus Pods pelo campo do Pod metadata.ownerReferences, que especifíca qual recurso é dono do objeto atual. Todos os Pods adquiridos por um ReplicaSet possuem as informações de identificação do ReplicaSet vinculado no campo ownerReferences. É por esse elo que o ReplicaSet tem conhecimento do estado dos Pods que está mantendo e assim faz seu planejamento.

Um ReplicaSet identifica novos Pods a serem adquiridos utilizando o seu seletor. Caso exista um Pod que não tenha OwnerReference ou se o OwnerReference não for um Controlador e o seu seletor corresponde com o do ReplicaSet, o Pod é adquirido imediatamente por esse ReplicaSet.

Quando usar um ReplicaSet

Um ReplicaSet garante que um número de réplicas de um Pod estão executando em qualquer momento. Entretanto, um Deployment é um conceito de nível superior que gerencia ReplicaSets e fornece atualizações declarativas aos Pods assim como várias outras funções úteis. Portanto, nós recomendamos a utilização de Deployments ao invés do uso direto de ReplicaSets, exceto se for preciso uma orquestração de atualização customizada ou que nenhuma atualização seja necessária.

Isso na realidade significa que você pode nunca precisar manipular objetos ReplicaSet: prefira usar um Deployment, e defina sua aplicação na seção spec.

Exemplo

controllers/frontend.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modifique o número de replicas de acordo com o seu caso
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

Salvando esse manifesto como frontend.yaml e submetendo no cluster Kubernetes irá criar o ReplicaSet definido e os Pods mantidos pelo mesmo.

kubectl apply -f https://kubernetes.io/pt-br/examples/controllers/frontend.yaml

Você pode então retornar os ReplicaSets atualmente existentes atualmente no cluster:

kubectl get rs

E observar o ReplicaSet com o nome de frontend que você criou:

NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       6s

Você também pode checar o estado do ReplicaSet:

kubectl describe rs/frontend

E você deve ver uma saída similar a esta:

Name:         frontend
Namespace:    default
Selector:     tier=frontend
Labels:       app=guestbook
              tier=frontend
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",...
Replicas:     3 current / 3 desired
Pods Status:  3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:  tier=frontend
  Containers:
   php-redis:
    Image:        gcr.io/google_samples/gb-frontend:v3
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  117s  replicaset-controller  Created pod: frontend-wtsmm
  Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-b2zdv
  Normal  SuccessfulCreate  116s  replicaset-controller  Created pod: frontend-vcmts

E por fim você consegue verificar os Pods que foram criados:

kubectl get pods

Você deve ver uma informação do Pod similar à esta:

NAME             READY   STATUS    RESTARTS   AGE
frontend-b2zdv   1/1     Running   0          6m36s
frontend-vcmts   1/1     Running   0          6m36s
frontend-wtsmm   1/1     Running   0          6m36s

Você consegue também validar que a referência de dono desses pods está definida para o ReplicaSet frontend. Para fazer isso, retorne o yaml de um dos Pods que estão executando:

kubectl get pods frontend-b2zdv -o yaml

O output será semelhante ao exibido abaixo, com as informações do ReplicaSet frontend definidas no campo ownerReferences dentro da metadata do Pod:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-02-12T07:06:16Z"
  generateName: frontend-
  labels:
    tier: frontend
  name: frontend-b2zdv
  namespace: default
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: frontend
    uid: f391f6db-bb9b-4c09-ae74-6a1f77f3d5cf
...

Aquisições de Pod sem Template

Enquanto você pode criar Pods diretamente sem problemas, é fortemente recomendado que você se certifique que esses Pods não tenham labels que combinem com o seletor de um dos seus ReplicaSets. O motivo para isso é que um ReplicaSet não é limitado a possuir apenas Pods estipulados por seu template -- ele pode adquirir outros Pods na maneira descrita nas seções anteriores.

Observe o exemplo anterior do ReplicaSet frontend, e seus Pods especificados no seguinte manifesto:

pods/pod-rs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    tier: frontend
spec:
  containers:
  - name: hello1
    image: gcr.io/google-samples/hello-app:2.0

---

apiVersion: v1
kind: Pod
metadata:
  name: pod2
  labels:
    tier: frontend
spec:
  containers:
  - name: hello2
    image: gcr.io/google-samples/hello-app:1.0

Como esses Pods não possuem um Controller (ou qualquer objeto) referenciados como seu dono e possuem labels que combinam com o seletor do ReplicaSet frontend, eles serão imediatamente adquiridos pelo ReplicaSet.

Imagine que você crie os Pods depois que o ReplicaSet frontend foi instalado e criou as réplicas de Pod inicial definida para cumprir o número de réplicas requiridas:

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

Os novos Pods serão adquiridos pelo ReplicaSet, e logo depois terminados já que o ReplicaSet estará acima do número desejado.

Buscando os Pods:

kubectl get pods

O output mostra que os novos Pods ou já estão terminados, ou estão no processo de ser terminados.

NAME             READY   STATUS        RESTARTS   AGE
frontend-b2zdv   1/1     Running       0          10m
frontend-vcmts   1/1     Running       0          10m
frontend-wtsmm   1/1     Running       0          10m
pod1             0/1     Terminating   0          1s
pod2             0/1     Terminating   0          1s

Se você criar os Pods primeiro:

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

mas em seguida criar o ReplicaSet:

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Você vai perceber que o ReplicaSet adquiriu os Pods e criou apenas novos de acordo com o seu spec até que o número de novo Pods e os Pods iniciais seja igual a ao número desejado. Listando os Pods:

kubectl get pods

Irá retornar a seguinte saída:

NAME             READY   STATUS    RESTARTS   AGE
frontend-hmmj2   1/1     Running   0          9s
pod1             1/1     Running   0          36s
pod2             1/1     Running   0          36s

Nesse sentido, um ReplicaSet pode possuir um grupo não-homogêneo de Pods

Escrevendo um manifesto ReplicaSet

Como todos os outros objetos de Kubernetes API, um ReplicaSet necessita dos campos apiVersion, kind, e metadata. Para ReplicaSets, o kind sempre será um ReplicaSet.

O nome de um objeto ReplicaSet precisa ser nome de subdomínio de DNS válido.

Um ReplicaSet também precisa de uma seção .spec.

Template de Pod

O .spec.template é um template de pod que também necessita de labels configurados. No nosso exemplo frontend.yaml nós temos uma label: tier: frontend. Fique atento para não sobrepor com seletores de outros controllers, para que eles não tentem adquirir esse Pod.

Para o campo de restart policy do template, .spec.template.spec.restartPolicy, o único valor permitido é Always, que é o padrão.

Seletor de Pod

O campo .spec.selector é um seletor de labels. Como discutido anteriormente esses são os labels usados para identificar Pods em potencial para aquisição. No nosso exemplo frontend.yaml, o seletor era:

matchLabels:
  tier: frontend

No ReplicaSet, .spec.template.metadata.labels precisa combinar com spec.selector, ou será rejeitado pela API.

Replicas

Você pode definir quantos Pods devem executar simultaneamente determinando .spec.replicas. O ReplicaSet irá criar/deletar os Pods para igualar à esse número.

Se você não especificar o .spec.replicas, seu padrão é 1.

Trabalhando com ReplicaSets

Deletando um ReplicaSet e seus Pods

Para deletar um ReplicaSet e todos os seus Pods, use kubectl delete. O Garbage collector automaticamente deleta todos os Pods dependentes por padrão.

Quando usar a API REST ou a biblioteca client-go, você precisa definir propagationPolicy para Background ou Foreground na opção -d. Por exemplo:

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
> -H "Content-Type: application/json"

Deletando apenas o ReplicaSet

Você consegue deletar um ReplicaSet sem afetar qualquer um dos Pods usando kubectl delete com a opção --cascade=orphan. Quando usar a API REST ou a biblioteca client-go, você precisa definir propagationPolicy para Orphan. Por exemplo:

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
> -H "Content-Type: application/json"

Quando o ReplicaSet original for deletado, você pode criar um novo ReplicaSet para substituí-lo. Contanto que o .spec.selector do antigo e do atual sejam o mesmo, o novo irá adquirir os Pods antigos. Porém, o ReplicaSet não atualizará as definições dos Pods existentes caso surja um novo e diferente template de pod. Para atualizar esses Pods para um novo spec de um modo controlado, use um Deployment, já que ReplicaSets não suportam um atualização gradual diretamente.

Isolando Pods de um ReplicaSet

Você pode remover Pods de um Replicaset trocando suas labels. Essa técnica pode ser usada para remover Pods de um serviço para depuração, recuperação de dados, etc. Pods que forem removidos por esse método serão substituídos imediatamente (assumindo que o número de replicas não tenha sido alterado).

Escalonando um ReplicaSet

Um ReplicaSet pode ser facilmente escalonado para cima ou para baixo simplesmente atualizando o campo de .spec.replicas. O Replicaset controller garante que o número desejado de Pods com um seletor de label correspondente estejam disponíveis e operando.

Ao escalonar para baixo, o Replicaset controller escolhe quais pods irá deletar ordenando os pods disponíveis para priorizar quais pods seram escalonados para baixo seguindo o seguinte algoritmo geral:

1. Pods pendentes (e não agendáveis) são decaídos primeiro
2. Se a anotação controller.kubernetes.io/pod-deletion-cost estiver definida, então o pod com o menor valor será priorizado primeiro.
3. Pods em nós com mais réplicas são decaídos primeiro que pods em nodes com menos réplicas.
4. Se a data de criação dos pods for diferente, o pod que foi criado mais recentemente vem antes que o pod mais antigo (as datas de criação são guardados em uma escala logarítmica caso o feature gate LogarithmicScaleDown esteja habilitado)

Se o Pod obedecer todos os items acima simultaneamente, a seleção é aleatória.

Custo de deleção de Pods

Utilizando a anotação controller.kubernetes.io/pod-deletion-cost, usuários podem definir uma preferência em relação à quais pods serão removidos primeiro caso o ReplicaSet precise escalonar para baixo.

A anotação deve ser definida no pod, com uma variação de [-2147483648, 2147483647]. Isso representa o custo de deletar um pod comparado com outros pods que pertencem à esse mesmo ReplicaSet. Pods com um custo de deleção menor são eleitos para deleção antes de pods com um custo maior.

O valor implícito para essa anotação para pods que não a tem definida é 0; valores negativos são permitidos. Valores inválidos serão rejeitados pelo servidor API.

Esse recurso está em beta e é habilitado por padrão. Você consegue desabilita-lo usando o feature gate PodDeletionCost ambos no kube-apiserver e no kube-controller-manager.

Exemplo de caso de uso

Os diferentes Pods de uma aplicação podem ter níveis de utilização divergentes. Ao escalonar para baixo, a aplicação pode preferir remover os pods com a menor utilização. Para evitar atualizações frequentes nos pods, a aplicação deve atualizar controller.kubernetes.io/pod-deletion-cost uma vez antes de expedir o escalonamento para baixo das réplicas (configurando a anotação para um valor proporcional ao nível de utilização do Pod). Isso funciona se a própria aplicação controlar o escalonamento; por exemplo, o pod condutor de um Deployment de Spark.

ReplicaSet como um Horizontal Pod Autoscaler Target

Um ReplicaSet pode também ser controlado por um Horizontal Pod Autoscalers (HPA). Isto é, um ReplicaSet pode ser automaticamente escalonado por um HPA. Aqui está um exemplo de um HPA controlando o ReplicaSet que nós criamos no exemplo anterior.

controllers/hpa-rs.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: ReplicaSet
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Salvando esse manifesto como hpa-rs.yaml e enviando para o cluster Kubernetes deve criar um HPA definido que autoescalona o ReplicaSet controlado dependendo do uso de CPU dos Pods replicados.

kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml

Alternativamente, você pode usar o comando kubectl autoscale para realizar a mesma coisa (e é bem mais simples!)

kubectl autoscale rs frontend --max=10 --min=3 --cpu=50%

Alternativas ao ReplicaSet

Deployment (recomendado)

Deployment é um objeto o qual pode possuir ReplicaSets, atualizá-los e por consequência seus Pods via atualizações declarativas, gradativas do lado do servidor. Enquanto ReplicaSets conseguem ser usados independentemente, hoje eles são principalmente usados por Deployments como um mecanismo para orquestrar a criação, deleção e atualização de um Pod. Quando você usa Deployments você não precisa se preocupar com o gerenciamento de ReplicaSets que são criados por ele. Deployments controlam e gerenciam seus ReplicaSets. Por isso, é recomendado o uso de Deployments quando você deseja ReplicaSets.

Bare Pods

Diferente do caso onde um usuário cria Pods diretamente, um ReplicaSet substitui Pods que forem deletados ou terminados por qualquer motivo, como em caso de falha de nó ou manutenção disruptiva de nó, como uma atualização de kernel. Por esse motivo, nós recomendamos que você use um ReplicaSet mesmo que sua aplicação necessite apenas de um único Pod. Pense na semelhança com um supervisor de processos, apenas que ele supervisione vários Pods em múltiplos nós ao invés de apenas um Pod. Um ReplicaSet delega reinicializações de um contêiner local para algum agente do nó (Kubelet ou Docker, por exemplo).

Job

Use um Job no lugar de um ReplicaSet para Pods que tem por objetivo sua terminação no final da execução (como batch jobs).

DaemonSet

Use um DaemonSet no lugar de um ReplicaSet para Pods que precisam prover funções no nível de sistema, como monitoramento do sistema ou logs do sistema. Esses Pods tem um tempo de vida ligado à vida útil do sistema: os Pods precisam estar executando na máquina antes de outros Pods inicializarem, e são seguros de terminarem quando a máquina esta preparada para reiniciar/desligar.

ReplicationController

ReplicaSets são sucessores ao ReplicationControllers. Os dois servem para o mesmo propósito, e tem comportamentos semelhantes, exceto que um ReplicationController não suporta os requerimentos de um seletor baseado em definição como descrito no guia de usuário de label. Portanto, ReplicaSets são preferíveis à ReplicationControllers

Próximos passos

• Aprenda sobre Pods.
• Aprenda sobre Deployments.
• Executar uma aplicação Stateless usando um Deployment, o qual necessita de ReplicaSets para funcionar.
• ReplicaSet é um recurso alto nível na API REST do Kubernetes. Leia a ReplicaSet definição de objeto para entender a API para replica sets.
• Leia sobre PodDisruptionBudget e como você consegue usá-lo para gerenciar disponibilidade de aplicação durante interrupções.

2.2 - CronJob

Um CronJob cria Jobs em um cronograma recorrente.

Um objeto CronJob é como uma linha em um arquivo crontab (tabela cron). Executa uma tarefa periodicamente em um determinado cronograma, escrito no formato Cron.

Ao criar o manifesto para um objeto CronJob, verifique se o nome que você forneceu é um nome de subdomínio DNS válido. O nome não pode ter mais que 52 caracteres. Esta limitação existe porque o controlador do CronJob adicionará automaticamente 11 caracteres ao final do nome escolhido para a tarefa, e o tamanho máximo de um nome de tarefa não pode ultrapassar 63 caracteres.

CronJob

CronJobs são úteis para criar tarefas periódicas e recorrentes, como a execução de backups ou o envio de mensagens de e-mail. CronJobs também permitem o agendamento de tarefas individuais para um horário específico, como por exemplo uma tarefa que é executada em um período maior de ociosidade do cluster.

Exemplo

Este manifesto de CronJob de exemplo imprime a data e horário atuais, seguidos da mensagem "Hello from the Kubernetes cluster", uma vez por minuto:

application/job/cronjob.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

(O artigo Running Automated Tasks with a CronJob demonstra este exemplo com maiores detalhes).

Sintaxe do cronograma cron

# ┌───────────── minuto (0 - 59)
# │ ┌───────────── hora (0 - 23)
# │ │ ┌───────────── dia do mês (1 - 31)
# │ │ │ ┌───────────── mês (1 - 12)
# │ │ │ │ ┌───────────── dia da semana (0 - 6) (domingo a sábado;
# │ │ │ │ │                                 7 também representa domingo em alguns sistemas operacionais)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *

Por exemplo, a linha abaixo determina que a tarefa deve iniciar toda sexta-feira à meia-noite, bem como em todo dia 13 do mês à meia-noite:

0 0 13 * 5

É também possível gerar expressões de cronograma para CronJobs utilizando ferramentas da web como o crontab.guru.

Limitações do CronJob

Um CronJob cria uma tarefa aproximadamente uma vez por tempo de execução de seu cronograma. Dizemos "aproximadamente" porque existem circunstâncias em que duas tarefas podem ser criadas, e outras circunstâncias em que nenhuma tarefa será criada. Tentamos tornar estas situações raras, mas não é possível preveni-las completamente. Portanto, as tarefas devem ser idempotentes.

Se o valor da propriedade startingDeadlineSeconds (limite de tempo de inicialização, em segundos) estiver definido como um valor grande, ou não definido (o padrão), e se a propriedade concurrencyPolicy (política de concorrência) estiver definido como Allow (permitir), as tarefas sempre serão executadas pelo menos uma vez.

Para cada CronJob, o controlador do CronJob verifica quantos agendamentos foram perdidos no tempo entre o último horário agendado e o horário atual. Se houver mais de 100 agendamentos perdidos no período, o controlador não iniciará o trabalho e gerará a seguinte mensagem de erro:

Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.

É importante observar que, se o campo startingDeadlineSeconds estiver definido (não nil), o controlador contará quantas tarefas perdidas ocorreram a partir do valor de startingDeadlineSeconds até agora, e não do último horário agendado até agora. Por exemplo, se startingDeadlineSeconds for 200, o controlador contará quantas tarefas perdidas ocorreram nos últimos 200 segundos.

Um CronJob é considerado perdido se não for criado no horário agendado. Por exemplo, se concurrencyPolicy estiver definido como Forbid (proibir) e uma tentativa de agendamento de um novo CronJob ocorreu quando havia um agendamento anterior ainda em execução, o novo agendamento será contabilizado como perdido.

Por exemplo, suponha que um CronJob esteja definido para agendar uma nova tarefa a cada minuto, começando às 08:30:00, e seu campo startingDeadlineSeconds não esteja definido. Se o controlador do CronJob estiver inativo das 08:29:00 até as 10:21:00, a tarefa não será iniciada, pois o número de tarefas que perderam seus horários agendados é maior que 100.

Para ilustrar melhor este conceito, suponha que um CronJob esteja definido para agendar uma nova tarefa a cada minuto, começando às 08:30:00, e seu startingDeadlineSeconds esteja definido em 200 segundos. Se o controlador do CronJob estiver inativo no mesmo período do exemplo anterior (das 08:29:00 às 10:21:00), a tarefa ainda será iniciada às 10:22:00. Isso acontece pois o controlador agora verifica quantos agendamentos perdidos ocorreram nos últimos 200 segundos (ou seja, 3 agendamentos perdidos), ao invés de verificar o período entre o último horário agendado e o horário atual.

O CronJob é responsável apenas pela criação das tarefas que correspondem à sua programação, e a tarefa, por sua vez, é responsável pelo gerenciamento dos Pods que ele representa.

Versão do controlador

A partir da versão 1.21 do Kubernetes, a segunda versão do controlador do CronJob é a implementação ativada por padrão. Para desativar o controlador do CronJob padrão e utilizar a versão original do controlador do CronJob, é necessário adicionar o flag de feature gate CronJobControllerV2 à chamada do kube-controller-manager com o valor false (falso). Por exemplo:

--feature-gates="CronJobControllerV2=false"

Próximos passos

A página Cron expression format documenta o formato dos campos de agendamento do CronJob.

Para instruções sobre criação e utilização de tarefas cron, e para um exemplo de manifesto de CronJob, veja Running automated tasks with cron jobs.

3 - Visão Geral

Essa página é uma visão geral do Kubernetes.

Kubernetes é um plataforma de código aberto, portável e extensiva para o gerenciamento de cargas de trabalho e serviços distribuídos em contêineres, que facilita tanto a configuração declarativa quanto a automação. Ele possui um ecossistema grande, e de rápido crescimento. Serviços, suporte, e ferramentas para Kubernetes estão amplamente disponíveis.

O Google tornou Kubernetes um projeto de código-aberto em 2014. O Kubernetes combina mais de 15 anos de experiência do Google executando cargas de trabalho produtivas em escala, com as melhores idéias e práticas da comunidade.

O nome Kubernetes tem origem no Grego, significando timoneiro ou piloto. K8s é a abreviação derivada pela troca das oito letras "ubernete" por "8", se tornado K"8"s.

Voltando no tempo

Vamos dar uma olhada no porque o Kubernetes é tão útil, voltando no tempo.

Era da implantação tradicional: No início, as organizações executavam aplicações em servidores físicos. Não havia como definir limites de recursos para aplicações em um mesmo servidor físico, e isso causava problemas de alocação de recursos. Por exemplo, se várias aplicações fossem executadas em um mesmo servidor físico, poderia haver situações em que uma aplicação ocupasse a maior parte dos recursos e, como resultado, o desempenho das outras aplicações seria inferior. Uma solução para isso seria executar cada aplicação em um servidor físico diferente. Mas isso não escalava, pois os recursos eram subutilizados, e se tornava custoso para as organizações manter muitos servidores físicos.

Era da implantação virtualizada: Como solução, a virtualização foi introduzida. Esse modelo permite que você execute várias máquinas virtuais (VMs) em uma única CPU de um servidor físico. A virtualização permite que as aplicações sejam isoladas entre as VMs, e ainda fornece um nível de segurança, pois as informações de uma aplicação não podem ser acessadas livremente por outras aplicações.

A virtualização permite melhor utilização de recursos em um servidor físico, e permite melhor escalabilidade porque uma aplicação pode ser adicionada ou atualizada facilmente, reduz os custos de hardware e muito mais. Com a virtualização, você pode apresentar um conjunto de recursos físicos como um cluster de máquinas virtuais descartáveis.

Cada VM é uma máquina completa que executa todos os componentes, incluindo seu próprio sistema operacional, além do hardware virtualizado.

Era da implantação em contêineres: Contêineres são semelhantes às VMs, mas têm propriedades de isolamento flexibilizados para compartilhar o sistema operacional (SO) entre as aplicações. Portanto, os contêineres são considerados leves. Semelhante a uma VM, um contêiner tem seu próprio sistema de arquivos, compartilhamento de CPU, memória, espaço de processo e muito mais. Como eles estão separados da infraestrutura subjacente, eles são portáveis entre nuvens e distribuições de sistema operacional.

Contêineres se tornaram populares porque eles fornecem benefícios extra, tais como:

• Criação e implantação ágil de aplicações: aumento da facilidade e eficiência na criação de imagem de contêiner comparado ao uso de imagem de VM.
• Desenvolvimento, integração e implantação contínuos: fornece capacidade de criação e de implantação de imagens de contêiner de forma confiável e frequente, com a funcionalidade de efetuar reversões rápidas e eficientes (devido à imutabilidade da imagem).
• Separação de interesses entre Desenvolvimento e Operações: crie imagens de contêineres de aplicações no momento de construção/liberação em vez de no momento de implantação, desacoplando as aplicações da infraestrutura.
• A capacidade de observação (Observabilidade) não apenas apresenta informações e métricas no nível do sistema operacional, mas também a integridade da aplicação e outros sinais.
• Consistência ambiental entre desenvolvimento, teste e produção: funciona da mesma forma em um laptop e na nuvem.
• Portabilidade de distribuição de nuvem e sistema operacional: executa no Ubuntu, RHEL, CoreOS, localmente, nas principais nuvens públicas e em qualquer outro lugar.
• Gerenciamento centrado em aplicações: eleva o nível de abstração da execução em um sistema operacional em hardware virtualizado à execução de uma aplicação em um sistema operacional usando recursos lógicos.
• Microserviços fracamente acoplados, distribuídos, elásticos e livres: as aplicações são divididas em partes menores e independentes e podem ser implantados e gerenciados dinamicamente - não uma pilha monolítica em execução em uma grande máquina de propósito único.
• Isolamento de recursos: desempenho previsível de aplicações.
• Utilização de recursos: alta eficiência e densidade.

Por que você precisa do Kubernetes e o que ele pode fazer

Os contêineres são uma boa maneira de agrupar e executar suas aplicações. Em um ambiente de produção, você precisa gerenciar os contêineres que executam as aplicações e garantir que não haja tempo de inatividade. Por exemplo, se um contêiner cair, outro contêiner precisa ser iniciado. Não seria mais fácil se esse comportamento fosse controlado por um sistema?

É assim que o Kubernetes vem ao resgate! O Kubernetes oferece uma estrutura para executar sistemas distribuídos de forma resiliente. Ele cuida do escalonamento e da recuperação à falha de sua aplicação, fornece padrões de implantação e muito mais. Por exemplo, o Kubernetes pode gerenciar facilmente uma implantação no método canário para seu sistema.

O Kubernetes oferece a você:

• Descoberta de serviço e balanceamento de carga O Kubernetes pode expor um contêiner usando o nome DNS ou seu próprio endereço IP. Se o tráfego para um contêiner for alto, o Kubernetes pode balancear a carga e distribuir o tráfego de rede para que a implantação seja estável.
• Orquestração de armazenamento O Kubernetes permite que você monte automaticamente um sistema de armazenamento de sua escolha, como armazenamentos locais, provedores de nuvem pública e muito mais.
• Lançamentos e reversões automatizadas Você pode descrever o estado desejado para seus contêineres implantados usando o Kubernetes, e ele pode alterar o estado real para o estado desejado em um ritmo controlado. Por exemplo, você pode automatizar o Kubernetes para criar novos contêineres para sua implantação, remover os contêineres existentes e adotar todos os seus recursos para o novo contêiner.
• Empacotamento binário automático Você fornece ao Kubernetes um cluster de nós que pode ser usado para executar tarefas nos contêineres. Você informa ao Kubernetes de quanta CPU e memória (RAM) cada contêiner precisa. O Kubernetes pode encaixar contêineres em seus nós para fazer o melhor uso de seus recursos.
• Autocorreção O Kubernetes reinicia os contêineres que falham, substitui os contêineres, elimina os contêineres que não respondem à verificação de integridade definida pelo usuário e não os anuncia aos clientes até que estejam prontos para servir.
• Gerenciamento de configuração e de segredos O Kubernetes permite armazenar e gerenciar informações confidenciais, como senhas, tokens OAuth e chaves SSH. Você pode implantar e atualizar segredos e configuração de aplicações sem reconstruir suas imagens de contêiner e sem expor segredos em sua pilha de configuração.

O que o Kubernetes não é

O Kubernetes não é um sistema PaaS (plataforma como serviço) tradicional e completo. Como o Kubernetes opera no nível do contêiner, e não no nível do hardware, ele fornece alguns recursos geralmente aplicáveis comuns às ofertas de PaaS, como implantação, escalonamento, balanceamento de carga, e permite que os usuários integrem suas soluções de logging, monitoramento e alerta. No entanto, o Kubernetes não é monolítico, e essas soluções padrão são opcionais e conectáveis. O Kubernetes fornece os blocos de construção para a construção de plataformas de desenvolvimento, mas preserva a escolha e flexibilidade do usuário onde é importante.

Kubernetes:

• Não limita os tipos de aplicações suportadas. O Kubernetes visa oferecer suporte a uma variedade extremamente diversa de cargas de trabalho, incluindo cargas de trabalho sem estado, com estado e de processamento de dados. Se uma aplicação puder ser executada em um contêiner, ele deve ser executado perfeitamente no Kubernetes.
• Não implanta código-fonte e não constrói sua aplicação. Os fluxos de trabalho de integração contínua, entrega e implantação (CI/CD) são determinados pelas culturas e preferências da organização, bem como pelos requisitos técnicos.
• Não fornece serviços em nível de aplicação, tais como middleware (por exemplo, barramentos de mensagem), estruturas de processamento de dados (por exemplo, Spark), bancos de dados (por exemplo, MySQL), caches, nem sistemas de armazenamento em cluster (por exemplo, Ceph), como serviços integrados. Esses componentes podem ser executados no Kubernetes e/ou podem ser acessados por aplicações executadas no Kubernetes por meio de mecanismos portáteis, como o Open Service Broker.
• Não dita soluções de logging, monitoramento ou alerta. Ele fornece algumas integrações como prova de conceito e mecanismos para coletar e exportar métricas.
• Não fornece nem exige um sistema/idioma de configuração (por exemplo, Jsonnet). Ele fornece uma API declarativa que pode ser direcionada por formas arbitrárias de especificações declarativas.
• Não fornece nem adota sistemas abrangentes de configuração de máquinas, manutenção, gerenciamento ou autocorreção.
• Adicionalmente, o Kubernetes não é um mero sistema de orquestração. Na verdade, ele elimina a necessidade de orquestração. A definição técnica de orquestração é a execução de um fluxo de trabalho definido: primeiro faça A, depois B e depois C. Em contraste, o Kubernetes compreende um conjunto de processos de controle independentes e combináveis que conduzem continuamente o estado atual em direção ao estado desejado fornecido. Não importa como você vai de A para C. O controle centralizado também não é necessário. Isso resulta em um sistema que é mais fácil de usar e mais poderoso, robusto, resiliente e extensível.

Próximos passos

• Dê uma olhada em Componentes do Kubernetes.
• Pronto para Iniciar?

3.1 - Componentes do Kubernetes

Ao implantar o Kubernetes, você obtém um cluster.

Um cluster Kubernetes consiste em um conjunto de servidores de processamento, chamados nós, que executam aplicações conteinerizadas. Todo cluster possui ao menos um servidor de processamento (worker node).

O(s) servidor(es) de processamento hospeda(m) os Pods, que são componentes de uma aplicação. A camada de gerenciamento gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção, a camada de gerenciamento geralmente executa em múltiplos computadores e um cluster geralmente executa múltiplos nós, fornecendo tolerância a falhas e alta disponibilidade.

Este documento descreve os vários componentes que você precisa ter para implantar um cluster Kubernetes completo e funcional.

Componentes da camada de gerenciamento

Os componentes da camada de gerenciamento tomam decisões globais sobre o cluster (por exemplo, alocação de Pods), bem como detectam e respondem aos eventos do cluster (por exemplo, inicialização de um novo Pod quando o campo replicas de um Deployment não está atendido).

Os componentes da camada de gerenciamento podem ser executados em qualquer máquina do cluster. Contudo, para simplificar, os scripts de configuração normalmente iniciam todos os componentes da camada de gerenciamento na mesma máquina, e contêineres com cargas de trabalho do usuário não rodam nesta máquina. Veja Construindo clusters altamente disponíveis com o kubeadm para um exemplo de configuração da camada de gerenciamento que roda em múltiplas máquinas.

kube-apiserver

O servidor da API é um componente da camada de gerenciamento do Kubernetes que expõe a API do Kubernetes. O servidor da API é o front end para a camada de gerenciamento do Kubernetes.

A principal implementação de um servidor de API do Kubernetes é o kube-apiserver. O kube-apiserver foi projetado para ser escalonado horizontalmente — ou seja, ele pode ser escalonado com a criação de mais instâncias. Você pode executar várias instâncias do kube-apiserver e distribuir o tráfego entre essas instâncias.

etcd

Armazenamento do tipo chave-valor consistente e de alta-disponibilidade, usado como armazenamento de apoio do Kubernetes para todos os dados do cluster.

Se o seu cluster Kubernetes usa o etcd como seu armazenamento de apoio, certifique-se de ter um plano de backup para seus dados.

Você pode encontrar informações detalhadas sobre o etcd na documentação oficial.

kube-scheduler

Componente da camada de gerenciamento que observa os Pods recém-criados e que ainda não foram atribuídos a um nó, e seleciona um nó para executá-los.

Os fatores levados em consideração para as decisões de alocação incluem: requisitos de recursos individuais e coletivos, restrições de hardware/software/política, especificações de afinidade e antiafinidade, localidade de dados, interferência entre cargas de trabalho, e prazos.

kube-controller-manager

Componente da camada de gerenciamento que executa os processos de controlador.

Logicamente, cada controlador está em um processo separado, mas para reduzir a complexidade, eles todos são compilados num único binário e executam em um processo único.

Alguns tipos desses controladores são:

• Controlador de nó: responsável por perceber e responder quando os nós caem.
• Controlador de Jobs: observa os objetos Job, que representam tarefas únicas, e em seguida cria Pods para executar essas tarefas até a conclusão.
• Controlador de EndpointSlice: preenche o objeto EndpointSlice (conecta os objetos Service e Pod).
• Controlador de ServiceAccount: cria a ServiceAccount default para novos namespaces.

cloud-controller-manager

O cloud-controller-manager executa apenas controladores que são específicos para seu provedor de nuvem. Se você estiver executando o Kubernetes em suas próprias instalações ou em um ambiente de aprendizagem dentro de seu próprio PC, o cluster não possui um gerenciador de controlador de nuvem.

Tal como acontece com o kube-controller-manager, o cloud-controller-manager combina vários ciclos de controle logicamente independentes em um binário único que você executa como um processo único. Você pode escalonar horizontalmente (executar mais de uma cópia) para melhorar o desempenho ou para auxiliar na tolerância a falhas.

Os seguintes controladores podem ter dependências de provedor de nuvem:

• Controlador de nó: para verificar junto ao provedor de nuvem para determinar se um nó foi excluído da nuvem após parar de responder.
• Controlador de rota: para configurar rotas na infraestrutura de nuvem subjacente.
• Controlador de serviço: para criar, atualizar e excluir balanceadores de carga do provedor de nuvem.

Componentes do nó

Os componentes do nó são executados em todos os nós, mantendo os Pods em execução e fornecendo o ambiente de execução do Kubernetes.

kubelet

Um agente que é executado em cada nó no cluster. Ele garante que os contêineres estejam sendo executados em um Pod.

O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente. O kubelet não gerencia contêineres que não foram criados pelo Kubernetes.

kube-proxy

kube-proxy é um proxy de rede executado em cada nó no seu cluster, implementando parte do conceito de serviço do Kubernetes.

kube-proxy mantém regras de rede nos nós. Estas regras de rede permitem a comunicação de rede com seus pods a partir de sessões de rede dentro ou fora de seu cluster.

kube-proxy usa a camada de filtragem de pacotes do sistema operacional se houver uma e estiver disponível. Caso contrário, o kube-proxy encaminha o tráfego ele mesmo.

Agente de execução de contêiner

O agente de execução (runtime) de contêiner é o software responsável por executar os contêineres.

O Kubernetes suporta diversos agentes de execução de contêineres: Docker, containerd, CRI-O, e qualquer implementação do Kubernetes CRI (Container Runtime Interface).

Complementos (addons)

Complementos (addons) usam recursos do Kubernetes (DaemonSet, Deployment, etc) para implementar funcionalidades do cluster. Como fornecem funcionalidades em nível do cluster, recursos de complementos que necessitem ser criados dentro de um namespace pertencem ao namespace kube-system.

Alguns complementos selecionados são descritos abaixo; para uma lista estendida dos complementos disponíveis, consulte Instalando Complementos.

DNS

Embora os outros complementos não sejam estritamente necessários, todos os clusters do Kubernetes devem ter um DNS do cluster, já que muitos exemplos dependem disso.

O DNS do cluster é um servidor DNS, além de outros servidores DNS em seu ambiente, que fornece registros DNS para serviços do Kubernetes.

Os contêineres iniciados pelo Kubernetes incluem automaticamente esse servidor DNS em suas pesquisas DNS.

Web UI (Dashboard)

O dashboard é uma interface de usuário Web, de uso geral, para clusters do Kubernetes. Ele permite que os usuários gerenciem e solucionem problemas de aplicações em execução no cluster, bem como o próprio cluster.

Monitoramento de recursos do contêiner

O monitoramento de recursos do contêiner registra métricas de série temporal genéricas sobre os contêineres em um banco de dados central e fornece uma interface de usuário para navegar por esses dados.

Logging a nivel do cluster

Um mecanismo de logging a nível do cluster é responsável por guardar os logs dos contêineres em um armazenamento central de logs com uma interface para navegação/pesquisa.

Próximos passos

• Aprenda sobre Nós.
• Aprenda sobre Controladores.
• Aprenda sobre kube-scheduler.
• Leia a documentação oficial do etcd.

3.2 - Objetos do Kubernetes

3.2.1 - Entendendo os objetos do Kubernetes

Esta página explica como os objetos do Kubernetes são representados na API do Kubernetes e como você pode expressá-los no formato .yaml.

Entendendo os objetos do Kubernetes

Os objetos do Kubernetes são entidades persistentes no Kubernetes. Kubernetes utiliza estas entidades para representar o estado do cluster. Especificamente, eles podem descrever:

• Quais aplicativos estão sendo executados (e em quais nós).
• Os recursos disponíveis para esses aplicativos
• As políticas acerca de como esses aplicativos se comportam, como políticas de reinicialização e tolerâncias a falhas.

Um objeto do Kubernetes é um “registro de intenção”-uma vez criado o objeto, o sistema do Kubernetes trabalha constantemente para garantir que este objeto existe. Ao criar um objeto, você está efetivamente falando para o sistema do Kubernetes como você quer que a carga do seu cluster seja. Este é o estado desejado do seu cluster.

Para trabalhar com objetos do Kubernetes seja para criar, modificar ou deletar eles, você precisará usar a API do Kubernetes. Quando você usa a interface de linha de comando do kubectl, por exemplo, o CLI faz as chamadas necessárias na API do Kubernetes para você. Você também pode usar a API do Kubernetes diretamente no seu próprio programa usando uma das Bibliotecas.

Especificação e status do objeto

Quase todos os objetos do Kubernetes incluem dois campos de objetos aninhados que governam a configuração do objeto: a especificação do objeto e o status do objeto. Para objetos que têm especificação, você tem que definir isso quando você cria o objeto, fornecendo uma descrição das características que você quer que o recurso tenha: o seu estado desejado.

O status descreve o estado atual do objeto, fornecido e atualizado pelo Kubernetes e seus componentes. A camada de gerenciamento do Kubernetes gerência continuamente e ativamente o real estado para corresponder ao estado desejado que você forneceu.

Por exemplo, no Kubernetes, o Deployment é um objeto que pode representar uma aplicação executando no seu cluster. Quando você cria o Deployment, você pode alterar a especificaçãopara definir que você quer três réplicas da aplicação em execução simultânea. O Kubernetes lê as especificações do Deployment e inicia três instâncias do seu aplicativo desejado, atualizando o status para corresponder às suas especificações. Se uma dessas instâncias falhar (um status mudar), o Kubernetes responde as diferenças entre as especificações e o status fazendo uma correção-neste caso, iniciando uma instância de substituição.

Para mais informações sobre especificações do objeto, status e metadados, veja Kubernetes API Conventions.

Descrevendo um objeto Kubernetes

Quando se cria um objeto do Kubernetes, deve-se fornecer a especificação do objeto que descreve seu estado desejado, bem como algumas informações básicas sobre o objeto (como um nome, por exemplo). Quando utiliza a API Kubernetes para criar o objeto (diretamente ou via kubectl), essa solicitação de API deve incluir essa informação como JSON no corpo da solicitação. Na maioria das vezes, você fornece as informações ao comando kubectl em um arquivo .yaml. O comandokubectl converte a informação para JSON ao fazer a requisição para a API.

Aqui está um exemplo de arquivo .yaml que mostra os campos necessários e as especificações de objeto para uma implatação Kubernetes:

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # diz ao deployment para executar 2 pods que correspondam ao modelo
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Uma maneira de criar um Deployment usando um arquivo .yaml como o representado acima é usar o comando kubectl apply na interface de linha de comando kubectl, passando o arquivo .yaml como argumento. Aqui está um exemplo:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

A saída será similar a esta:

deployment.apps/nginx-deployment created

Campos obrigatórios

No arquivo .yaml para o objeto Kubernetes que pretende criar, você precisará definir valores para os seguintes campos:

• apiVersion - Qual a versão de API do objeto que será usado no Kubernetes para criar esse objeto.
• kind - Qual tipo de objeto pretende criar.
• metadata - Dados que ajudam a identificar de forma única o objeto, incluindo uma string nome, UID e um namespace.
• spec - Que estado deseja para o objeto.

O formato preciso do objeto spec é diferente para cada objeto Kubernetes, e contém campos aninhados específicos para aquele objeto. A documentação de referência da API do Kubernetes pode ajudar a encontrar o formato de especificação para todos os objetos que você pode criar usando Kubernetes.

Por exemplo, veja o campo de spec field para a referência Pod API. Para cada Pod, o campo .spec especifica o pod e seu estado desejado (como o nome da imagem do contêiner para cada recipiente dentro daquela cápsula). Outro exemplo de especificação de um objeto é o campo spec . Para o StatefulSet, o campo .spec especifica o StatefulSet e seu estado desejado. Dentro do .spec de um StatefulSet está um template para objetos de Pod. Esse modelo descreve os Pods que o controlador StatefulSet criará para satisfazer a especificação do StatefulSet. Diferentes tipos de objetos também podem ter diferentes .status; novamente, as páginas de referência API detalham a estrutura daquele campo .status, e seu conteúdo para cada tipo diferente de objeto.

Próximos passos

Aprenda sobre os mais importantes objetos básicos Kubernetes, como o Pod. Aprenda sobre as controladoras do Kubernetes. Usando a API Kubernetes explica mais alguns conceitos da API.

3.2.2 - Nomes de objetos e IDs

Cada objeto em seu cluster possui um Nome que é único para aquele tipo de recurso. Todo objeto do Kubernetes também possui um UID que é único para todo o cluster.

Por exemplo, você pode ter apenas um Pod chamado myapp-1234 dentro de um namespace, porém você pode ter um Pod e um Deployment ambos com o nome myapp-1234.

Para atributos não-únicos definidos pelo usuário, o Kubernetes fornece labels e annotations.

Nomes

Uma string fornecida pelo cliente que referencia um objeto em uma URL de recurso, como por exemplo /api/v1/pods/qualquer-nome.

Somente um objeto de um dado tipo pode ter um certo nome por vez. No entanto, se você remover o objeto, você poderá criar um novo objeto com o mesmo nome.

Abaixo estão descritos quatro tipos de restrições de nomes comumente utilizadas para recursos.

Nomes de subdomínio DNS

A maior parte dos recursos do Kubernetes requerem um nome que possa ser utilizado como um nome de subdomínio DNS, conforme definido na RFC 1123. Isso significa que o nome deve:

• conter no máximo 253 caracteres
• conter somente caracteres alfanuméricos em caixa baixa, traço ('-') ou ponto ('.').
• iniciar com um caractere alfanumérico
• terminar com um caractere alfanumérico

Nomes de rótulos da RFC 1123

Alguns tipos de recurso requerem que seus nomes sigam o padrão de rótulos DNS definido na RFC 1123. Isso significa que o nome deve:

• conter no máximo 63 caracteres
• conter somente caracteres alfanuméricos em caixa baixa ou traço ('-')
• iniciar com um caractere alfanumérico
• terminar com um caractere alfanumérico

Nomes de rótulo da RFC 1035

Alguns tipos de recurso requerem que seus nomes sigam o padrão de rótulos DNS definido na RFC 1035. Isso significa que o nome deve:

• conter no máximo 63 caracteres
• conter somente caracteres alfanuméricos em caixa baixa ou traço ('-')
• iniciar com um caractere alfanumérico
• terminar com um caractere alfanumérico

Nomes de segmentos de caminhos

Alguns tipos de recurso requerem que seus nomes possam ser seguramente codificados como um segmento de caminho, ou seja, o nome não pode ser "." ou ".." e não pode conter "/" ou "%".

Exemplo de um manifesto para um Pod chamado nginx-demo.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

UIDs

Uma string gerada pelos sistemas do Kubernetes para identificar objetos de forma única.

Cada objeto criado durante todo o ciclo de vida do cluster do Kubernetes possui um UID distinto. O objetivo deste identificador é distinguir ocorrências históricas de entidades semelhantes.

UIDs no Kubernetes são identificadores únicos universais (também conhecidos como UUIDs). UUIDs seguem os padrões ISO/IEC 9834-8 e ITU-T X.667.

Próximos passos

• Leia sobre labels no Kubernetes.
• Consulte o documento de design Identifiers and Names in Kubernetes.

3.2.3 - Namespaces

No Kubernetes, namespaces disponibilizam um mecanismo para isolar grupos de recursos dentro de um único cluster. Nomes de recursos precisam ser únicos dentro de um namespace, porém podem se repetir em diferentes namespaces. Escopos baseados em namespaces são aplicáveis apenas para objetos com namespace (como: Deployments, Services, etc) e não em objetos que abrangem todo o cluster (como: StorageClass, Nodes, PersistentVolumes, etc).

Quando Utilizar Múltiplos Namespaces

Namespaces devem ser utilizados em ambientes com múltiplos usuários espalhados por diversos times ou projetos. Para clusters com poucos ou até algumas dezenas de usuários, você não deveria precisar criar ou pensar a respeito de namespaces. Comece a utilizar namespaces quando você precisar das funcionalidades que eles oferecem.

Namespaces oferecem escopo para nomes. Nomes de recursos precisam ser únicos dentro de um namespace, porém não em diferentes namespaces. Namespaces não podem ser aninhados dentro de outros namespaces e cada recurso Kubernetes pode pertencer à apenas um namespace.

Namespaces nos permitem dividir os recursos do cluster entre diferentes usuários (via resource quota).

Não é necessário utilizar múltiplos namespaces para separar recursos levemente diferentes, como diferentes versões de um mesmo software: use labels para distinguir recursos dentro de um mesmo namespace.

Namespaces Iniciais

O Kubernetes é inicializado com quatro namespaces:

default

O Kubernetes inclui esse namespace para que você possa começar a usar seu novo cluster sem precisar criar um namespace primeiro.

kube-node-lease

Este namespace contém os objetos de Lease associados com cada node. Node leases permitem que o kubelet envie heartbeats para que a camada de gerenciamento detecte falhas nos nodes.

kube-public

Este namespace é criado automaticamente e é legível por todos os clientes (incluindo clientes não autenticados). Este namespace é reservado principalmente para uso do cluster, no caso de alguns recursos que precisem ser visíveis e legíveis publicamente por todo o cluster. O aspecto público deste namespace é apenas uma convenção, não um requisito.

kube-system

O namespace para objetos criados pelo sistema Kubernetes

Trabalhando com Namespaces

Criação e eliminação de namespaces estão descritas na documentação de namespaces do guia de administradores.

Visualizando namespaces

Você pode obter uma lista dos namespaces atuais dentro de um cluster com:

kubectl get namespace

NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

Preparando o namespace para uma requisição

Para preparar o namespace para a requisição atual, utilize o parâmetro --namespace. Por exemplo:

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

Configurando a preferência de namespaces

Você pode salvar permanentemente o namespace para todos os comandos kubectl subsequentes no mesmo contexto:

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validando
kubectl config view --minify | grep namespace:

Namespaces e DNS

Quando você cria um Serviço, ele cria uma entrada DNS correspondente. Esta entrada possui o formato: <service-name>.<namespace-name>.svc.cluster.local, de forma que se um contêiner utilizar apenas <service-name> ele será resolvido para um serviço que é local ao namespace. Isso é útil para utilizar a mesma configuração em vários namespaces, por exemplo em Desenvolvimento, Staging e Produção. Se você quiser acessar múltiplos namespaces, precisará utilizar um Fully Qualified Domain Name (FQDN).

Nomes de namespaces devem ser válidos conforme a RFC 1123 para rótulos DNS.

Nem todos os objetos pertencem a algum Namespace

A maior parte dos recursos Kubernetes (como Pods, Services, controladores de replicação e outros) pertencem a algum namespace. Entretanto, recursos de namespaces não pertencem a nenhum namespace. Além deles, recursos de baixo nível, como nodes e persistentVolumes, também não pertencem a nenhum namespace.

Para visualizar quais recursos Kubernetes pertencem ou não a algum namespace, utilize:

# Em um namespace
kubectl api-resources --namespaced=true

# Sem namespace
kubectl api-resources --namespaced=false

Rotulamento Automático

A camada de gerenciamento Kubernetes configura um label imutável kubernetes.io/metadata.name em todos os namespaces. O valor do label é o nome do namespace.

Próximos passos

• Leia sobre a criação de um novo namespace.
• Leia sobre a eliminação de um namespace.

3.2.4 - Seletores de Campos

Os Seletores de Campos permitem que você selecione recursos do Kubernetes baseado no valor de um ou mais campos de um recurso. Seguem alguns exemplos de buscas utilizando seletores de campos:

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

O comando kubectl, mostrado a seguir, seleciona todos os Pods nos quais o valor do campo status.phase é Running:

kubectl get pods --field-selector status.phase=Running

Campos suportados

Os campos de seleção suportados variam dependendo do tipo de recurso Kubernetes. Todos os tipos de recursos suportam os campos metadata.name e metadata.namespace. Utilizar campos não suportados produz um erro. Como por exemplo:

kubectl get ingress --field-selector foo.bar=baz

Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

Operadores suportados

Você pode utilizar os operadores =, == e != com seletores de campos (= e == significam a mesma coisa). Por exemplo, o comando kubectl a seguir seleciona todos os Kubernetes Services que não estão no namespace default:

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

Seletores em cadeia

Assim como label e outros tipos de seletores, podem ser utilizados em cadeia através de uma lista separada por vírgula. O comando kubectl a seguir seleciona todos os Pods nos quais status.phase não é igual a Running e spec.restartPolicy é igual a Always

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

Múltiplos tipos de recursos

Você pode utilizar seletores de campos através de múltiplos tipos de recursos. Por exemplo, o comando kubectl a seguir seleciona todos Statefulsets e Services que não estão presentes no namespace default.

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

4 - Arquitetura do Cluster

Um cluster Kubernetes consiste em um control plane mais um conjunto de máquinas trabalhadoras, chamadas de nodes, que executam aplicações conteinerizadas. Todo cluster precisa de pelo menos um worker node para executar Pods.

Os worker nodes hospedam os Pods que são os componentes da carga de trabalho da aplicação. O control plane gerencia os worker nodes e os Pods no cluster. Em ambientes de produção, o control plane geralmente executa em múltiplos computadores e um cluster geralmente executa múltiplos nodes, fornecendo tolerância a falhas e alta disponibilidade.

Este documento descreve os vários componentes que você precisa ter para um cluster Kubernetes completo e funcional.

Componentes do control plane

Os componentes do control plane tomam decisões globais sobre o cluster (por exemplo, agendamento), bem como detectam e respondem a eventos do cluster (por exemplo, iniciar um novo pod quando o campo replicas de um Deployment não está satisfeito).

Os componentes do control plane podem ser executados em qualquer máquina do cluster. No entanto, para simplicidade, scripts de configuração normalmente iniciam todos os componentes do control plane na mesma máquina, e não executam contêineres de usuário nesta máquina. Consulte Criando clusters altamente disponíveis com kubeadm para um exemplo de configuração do control plane que executa em múltiplas máquinas.

kube-apiserver

O servidor da API é um componente da camada de gerenciamento do Kubernetes que expõe a API do Kubernetes. O servidor da API é o front end para a camada de gerenciamento do Kubernetes.

A principal implementação de um servidor de API do Kubernetes é o kube-apiserver. O kube-apiserver foi projetado para ser escalonado horizontalmente — ou seja, ele pode ser escalonado com a criação de mais instâncias. Você pode executar várias instâncias do kube-apiserver e distribuir o tráfego entre essas instâncias.

etcd

Armazenamento do tipo chave-valor consistente e de alta-disponibilidade, usado como armazenamento de apoio do Kubernetes para todos os dados do cluster.

Se o seu cluster Kubernetes usa o etcd como seu armazenamento de apoio, certifique-se de ter um plano de backup para seus dados.

Você pode encontrar informações detalhadas sobre o etcd na documentação oficial.

kube-scheduler

Componente da camada de gerenciamento que observa os Pods recém-criados e que ainda não foram atribuídos a um nó, e seleciona um nó para executá-los.

Os fatores levados em consideração para as decisões de alocação incluem: requisitos de recursos individuais e coletivos, restrições de hardware/software/política, especificações de afinidade e antiafinidade, localidade de dados, interferência entre cargas de trabalho, e prazos.

kube-controller-manager

Componente da camada de gerenciamento que executa os processos de controlador.

Logicamente, cada controlador está em um processo separado, mas para reduzir a complexidade, eles todos são compilados num único binário e executam em um processo único.

Existem muitos tipos diferentes de controllers. Alguns exemplos deles são:

• Node controller: Responsável por notar e responder quando nodes ficam indisponíveis.
• Job controller: Observa objetos Job que representam tarefas pontuais, depois cria Pods para executar essas tarefas até a conclusão.
• EndpointSlice controller: Preenche objetos EndpointSlice (para fornecer um link entre Services e Pods).
• ServiceAccount controller: Cria ServiceAccounts padrão para novos namespaces.

A lista acima não é exaustiva.

cloud-controller-manager

O cloud-controller-manager executa apenas controllers que são específicos do seu provedor de nuvem. Se você está executando o Kubernetes em suas próprias instalações, ou em um ambiente de aprendizado dentro do seu próprio PC, o cluster não tem um cloud controller manager.

Assim como o kube-controller-manager, o cloud-controller-manager combina vários loops de controle logicamente independentes em um único binário que você executa como um único processo. Você pode escalar horizontalmente (executar mais de uma cópia) para melhorar o desempenho ou para ajudar a tolerar falhas.

Os seguintes controllers podem ter dependências do provedor de nuvem:

• Node controller: Para verificar o provedor de nuvem para determinar se um node foi excluído na nuvem após parar de responder
• Route controller: Para configurar rotas na infraestrutura de nuvem subjacente
• Service controller: Para criar, atualizar e excluir load balancers do provedor de nuvem

Componentes do node

Os componentes do node executam em cada node, mantendo pods em execução e fornecendo o ambiente de runtime do Kubernetes.

kubelet

Um agente que é executado em cada nó no cluster. Ele garante que os contêineres estejam sendo executados em um Pod.

O kubelet utiliza um conjunto de PodSpecs que são fornecidos por vários mecanismos e garante que os contêineres descritos nesses PodSpecs estejam funcionando corretamente. O kubelet não gerencia contêineres que não foram criados pelo Kubernetes.

kube-proxy (opcional)

kube-proxy é um proxy de rede executado em cada nó no seu cluster, implementando parte do conceito de serviço do Kubernetes.

kube-proxy mantém regras de rede nos nós. Estas regras de rede permitem a comunicação de rede com seus pods a partir de sessões de rede dentro ou fora de seu cluster.

kube-proxy usa a camada de filtragem de pacotes do sistema operacional se houver uma e estiver disponível. Caso contrário, o kube-proxy encaminha o tráfego ele mesmo.

Agente de execução de contêiner

O agente de execução (runtime) de contêiner é o software responsável por executar os contêineres.

O Kubernetes suporta diversos agentes de execução de contêineres: Docker, containerd, CRI-O, e qualquer implementação do Kubernetes CRI (Container Runtime Interface).

Addons

Addons usam recursos do Kubernetes (DaemonSet, Deployment, etc) para implementar funcionalidades do cluster. Como estes estão fornecendo funcionalidades no nível do cluster, recursos com namespace para addons pertencem ao namespace kube-system.

Addons selecionados são descritos abaixo; para uma lista estendida de addons disponíveis, consulte Addons.

DNS

Embora os outros addons não sejam estritamente necessários, todos os clusters Kubernetes devem ter DNS do cluster, pois muitos exemplos dependem dele.

DNS do cluster é um servidor DNS, além do(s) outro(s) servidor(es) DNS em seu ambiente, que serve registros DNS para services do Kubernetes.

Contêineres iniciados pelo Kubernetes automaticamente incluem este servidor DNS em suas buscas DNS.

Web UI (Dashboard)

Dashboard é uma UI baseada na web de propósito geral para clusters Kubernetes. Ela permite aos usuários gerenciar e solucionar problemas de aplicações executando no cluster, bem como o próprio cluster.

Monitoramento de recursos de contêiner

Monitoramento de Recursos de Contêiner grava métricas genéricas de séries temporais sobre contêineres em um banco de dados central, e fornece uma UI para navegar nesses dados.

Logging no nível do cluster

Um mecanismo de logging no nível do cluster é responsável por salvar logs de contêineres em um armazenamento central de logs com uma interface de busca/navegação.

Plugins de rede

Plugins de rede são componentes de software que implementam a especificação da interface de rede de contêineres (CNI). Eles são responsáveis por alocar endereços IP para pods e permitir que eles se comuniquem uns com os outros dentro do cluster.

Variações de arquitetura

Embora os componentes principais do Kubernetes permaneçam consistentes, a forma como eles são implantados e gerenciados pode variar. Entender essas variações é crucial para projetar e manter clusters Kubernetes que atendam às necessidades operacionais específicas.

Opções de implantação do control plane

Os componentes do control plane podem ser implantados de várias maneiras:

Implantação tradicional

Os componentes do control plane executam diretamente em máquinas dedicadas ou VMs, frequentemente gerenciados como serviços systemd.

Pods estáticos

Os componentes do control plane são implantados como Pods estáticos, gerenciados pelo kubelet em nodes específicos. Esta é uma abordagem comum usada por ferramentas como kubeadm.

Auto-hospedado

O control plane executa como Pods dentro do próprio cluster Kubernetes, gerenciado por Deployments e StatefulSets ou outras primitivas do Kubernetes.

Serviços gerenciados do Kubernetes

Provedores de nuvem frequentemente abstraem o control plane, gerenciando seus componentes como parte de sua oferta de serviço.

Considerações de posicionamento de carga de trabalho

O posicionamento de cargas de trabalho, incluindo os componentes do control plane, pode variar com base no tamanho do cluster, requisitos de desempenho e políticas operacionais:

• Em clusters menores ou de desenvolvimento, componentes do control plane e cargas de trabalho de usuário podem executar nos mesmos nodes.
• Clusters de produção maiores frequentemente dedicam nodes específicos aos componentes do control plane, separando-os das cargas de trabalho de usuário.
• Algumas organizações executam addons críticos ou ferramentas de monitoramento em nodes do control plane.

Ferramentas de gerenciamento de cluster

Ferramentas como kubeadm, kops e Kubespray oferecem diferentes abordagens para implantar e gerenciar clusters, cada uma com seu próprio método de layout e gerenciamento de componentes.

A flexibilidade da arquitetura do Kubernetes permite que organizações adaptem seus clusters às necessidades específicas, equilibrando fatores como complexidade operacional, desempenho e sobrecarga de gerenciamento.

Customização e extensibilidade

A arquitetura do Kubernetes permite customização significativa:

• Schedulers customizados podem ser implantados para trabalhar junto com o scheduler padrão do Kubernetes ou para substituí-lo completamente.
• Servidores de API podem ser estendidos com CustomResourceDefinitions e API Aggregation.
• Provedores de nuvem podem se integrar profundamente com o Kubernetes usando o cloud-controller-manager.

A flexibilidade da arquitetura do Kubernetes permite que organizações adaptem seus clusters às necessidades específicas, equilibrando fatores como complexidade operacional, desempenho e sobrecarga de gerenciamento.

Próximos passos

Saiba mais sobre o seguinte:

• Nodes e sua comunicação com o control plane.
• Controllers do Kubernetes.
• kube-scheduler que é o scheduler padrão para o Kubernetes.
• Documentação oficial do Etcd.
• Vários agentes de execução de contêiner no Kubernetes.
• Integrando com provedores de nuvem usando cloud-controller-manager.
• Comandos kubectl.

4.1 - Nós

O Kubernetes executa sua carga de trabalho colocando contêineres em Pods para serem executados em Nós. Um nó pode ser uma máquina virtual ou física, dependendo do cluster. Cada nó é gerenciado pela camada de gerenciamento e contém os serviços necessários para executar Pods.

Normalmente, você tem vários nós em um cluster; em um ambiente de aprendizado ou limitado por recursos, você pode ter apenas um nó.

Os componentes em um nó incluem o kubelet, um agente de execução de contêiner, e o kube-proxy.

Administração

Existem duas maneiras principais de adicionar Nós ao Servidor da API:

1. O kubelet em um nó se registra automaticamente na camada de gerenciamento
2. Você (ou outro usuário humano) adiciona manualmente um objeto Nó

Depois de criar um objeto Nó, ou o kubelet em um nó se registra automaticamente, a camada de gerenciamento verifica se o novo objeto Nó é válido. Por exemplo, se você tentar criar um nó a partir do seguinte manifesto JSON:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

O Kubernetes cria um objeto nó internamente (a representação). O Kubernetes verifica se um kubelet se registrou no servidor da API que corresponde ao campo metadata.name do Nó. Se o nó estiver íntegro (ou seja, todos os serviços necessários estiverem em execução), ele será elegível para executar um Pod. Caso contrário, esse nó é ignorado para qualquer atividade de cluster até que se torne íntegro.

O nome de um objeto nó deve ser um nome de subdomínio válido de DNS.

Singularidade de nome do nó

O nome identifica um nó. Dois nós não podem ter o mesmo nome ao mesmo tempo. O Kubernetes também assume que um recurso com o mesmo nome é o mesmo objeto. No caso de um nó, assume-se implicitamente que uma instância usando o mesmo nome terá o mesmo estado (por exemplo, configurações de rede, conteúdo do disco raiz) e atributos como label de nó. Isso pode levar a inconsistências se uma instância for modificada sem alterar seu nome. Se o nó precisar ser substituído ou atualizado significativamente, o objeto Nó existente precisa ser removido do servidor da API primeiro e adicionado novamente após a atualização.

Auto-registro de Nós

Quando a opção --register-node do kubelet for verdadeira (padrão), o kubelet tentará se registrar no servidor da API. Este é o padrão preferido, usado pela maioria das distribuições.

Para auto-registro, o kubelet é iniciado com as seguintes opções:

• --kubeconfig - O caminho das credenciais para se autenticar no servidor da API.
• --cloud-provider - Como comunicar com um provedor de nuvem para ler metadados sobre si mesmo.
• --register-node - Registrar automaticamente no servidor da API.
• --register-with-taints - Registra o nó com a lista fornecida de taints (separadas por vírgula <key>=<value>:<effect>).

Não funciona se o register-node for falso.

• --node-ip - endereço IP do nó.
• --node-labels - Labels a serem adicionados ao registrar o nó no cluster (consulte as restrições de label impostas pelo plug-in de admissão NodeRestriction).
• --node-status-update-frequency - Especifica com que frequência o kubelet publica o status do nó no servidor da API.

Quando o modo de autorização do nó e o plug-in de admissão NodeRestriction estão ativados, os kubelets somente estarão autorizados a criar/modificar seu próprio recurso do nó.

Administração manual de nós

Você pode criar e modificar objetos Nó usando o kubectl.

Quando você quiser manualmente criar objetos Nó, defina a opção do kubelet --register-node=false.

Você pode modificar os objetos Nó, independentemente da configuração de --register-node. Por exemplo, você pode definir labels em um nó existente ou marcá-lo como não disponível.

Você pode usar labels nos Nós em conjunto com seletores de nós nos Pods para controlar a disponibilidade. Por exemplo, você pode restringir um Pod a ser elegível apenas para ser executado em um subconjunto dos nós disponíveis.

Marcar um nó como não disponível impede que o escalonador coloque novos pods nesse nó, mas não afeta os Pods existentes no nó. Isso é útil como uma etapa preparatória antes da reinicialização de um nó ou outra manutenção.

Para marcar um nó como não disponível, execute:

kubectl cordon $NODENAME

Consulte Drenar um nó com segurança para obter mais detalhes.

Status do Nó

O status de um nó contém as seguintes informações:

• Endereços
• Condições
• Capacidade
• Informação

Você pode usar o kubectl para visualizar o status de um nó e outros detalhes:

kubectl describe node <insira-nome-do-nó-aqui>

Cada seção da saída está descrita abaixo.

Endereços

O uso desses campos pode mudar dependendo do seu provedor de nuvem ou configuração dedicada.

• HostName: O nome do host relatado pelo kernel do nó. Pode ser substituído através do parâmetro kubelet --hostname-override.
• ExternalIP: Geralmente, o endereço IP do nó que é roteável externamente (disponível fora do cluster).
• InternalIP: Geralmente, o endereço IP do nó que é roteável somente dentro do cluster.

Condições

O campo conditions descreve o status de todos os nós em execução. Exemplos de condições incluem:

Na API do Kubernetes, a condição de um nó é representada como parte do .status do recurso do nó. Por exemplo, a seguinte estrutura JSON descreve um nó íntegro:

"conditions": [
  {
    "type": "Ready",
    "status": "True",
    "reason": "KubeletReady",
    "message": "kubelet is posting ready status",
    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
    "lastTransitionTime": "2019-06-05T11:41:27Z"
  }
]

Se o status da condição Ready permanecer desconhecido (Unknown) ou falso (False) por mais tempo do que o limite da remoção do pod (pod-eviction-timeout) (um argumento passado para o kube-controller-manager), o controlador de nó acionará o remoção iniciado pela API para todos os Pods atribuídos a esse nó. A duração padrão do tempo limite da remoção é de cinco minutos. Em alguns casos, quando o nó está inacessível, o servidor da API não consegue se comunicar com o kubelet no nó. A decisão de excluir os pods não pode ser comunicada ao kubelet até que a comunicação com o servidor da API seja restabelecida. Enquanto isso, os pods agendados para exclusão podem continuar a ser executados no nó particionado.

O controlador de nós não força a exclusão dos pods até que seja confirmado que eles pararam de ser executados no cluster. Você pode ver os pods que podem estar sendo executados em um nó inacessível como estando no estado de terminando (Terminating) ou desconhecido (Unknown). Nos casos em que o Kubernetes não retirar da infraestrutura subjacente se um nó tiver deixado permanentemente um cluster, o administrador do cluster pode precisar excluir o objeto do nó manualmente. Excluir o objeto do nó do Kubernetes faz com que todos os objetos Pod em execução no nó sejam excluídos do servidor da API e libera seus nomes.

Quando ocorrem problemas nos nós, a camada de gerenciamento do Kubernetes cria automaticamente taints que correspondem às condições que afetam o nó. O escalonador leva em consideração as taints do Nó ao atribuir um Pod a um Nó. Os Pods também podem ter tolerations que os permitem funcionar em um nó, mesmo que tenha uma taint específica.

Consulte Nó Taint por Condição para mais detalhes.

Capacidade e Alocável

Descreve os recursos disponíveis no nó: CPU, memória e o número máximo de pods que podem ser agendados no nó.

Os campos no bloco de capacidade indicam a quantidade total de recursos que um nó possui. O bloco alocado indica a quantidade de recursos em um nó que está disponível para ser consumido por Pods normais.

Você pode ler mais sobre capacidade e recursos alocados enquanto aprende a reservar recursos de computação em um nó.

Info

Descreve informações gerais sobre o nó, como a versão do kernel, a versão do Kubernetes (versão do kubelet e kube-proxy), detalhes do tempo de execução do contêiner e qual sistema operacional o nó usa. O kubelet coleta essas informações do nó e as publica na API do Kubernetes.

Heartbeats

Os Heartbeats, enviados pelos nós do Kubernetes, ajudam seu cluster a determinar a disponibilidade de cada nó e a agir quando as falhas forem detectadas.

Para nós, existem duas formas de heartbeats:

• atualizações para o .status de um Nó
• Objetos Lease dentro do namespace kube-node-lease. Cada nó tem um objeto de Lease associado.

Em comparação com as atualizações no .status de um nó, um Lease é um recurso mais leve. O uso de Leases para heartbeats reduz o impacto no desempenho dessas atualizações para grandes clusters.

O kubelet é responsável por criar e atualizar o .status dos Nós e por atualizar suas Leases relacionadas.

• O kubelet atualiza o .status do nó quando há mudança de status ou se não houve atualização para um intervalo configurado. O intervalo padrão para atualizações .status para Nós é de 5 minutos, o que é muito maior do que o tempo limite padrão de 40 segundos para nós inacessíveis.
• O kubelet cria e atualiza seu objeto Lease a cada 10 segundos (o intervalo de atualização padrão). As atualizações de Lease ocorrem independentemente das atualizações no .status do Nó. Se a atualização do Lease falhar, o kubelet voltará a tentativas, usando um recuo exponencial que começa em 200 milissegundos e limitado a 7 segundos.

Controlador de Nós

O controlador de nós é um componente da camada de gerenciamento do Kubernetes que gerencia vários aspectos dos nós.

O controlador de nó tem várias funções na vida útil de um nó. O primeiro é atribuir um bloco CIDR ao nó quando ele é registrado (se a atribuição CIDR estiver ativada).

O segundo é manter a lista interna de nós do controlador de nós atualizada com a lista de máquinas disponíveis do provedor de nuvem. Ao ser executado em um ambiente de nuvem e sempre que um nó não é íntegro, o controlador de nó pergunta ao provedor de nuvem se a VM desse nó ainda está disponível. Caso contrário, o controlador de nós exclui o nó de sua lista de nós.

O terceiro é monitorar a saúde dos nós. O controlador do nó é responsável por:

• No caso de um nó se tornar inacessível, atualizar a condição NodeReady dentro do campo .status do nó. Nesse caso, o controlador do nó define a condição de pronto (NodeReady) como condição desconhecida (ConditionUnknown).
• Se um nó permanecer inacessível: será iniciado a remoção pela API para todos os Pods no nó inacessível. Por padrão, o controlador do nó espera 5 minutos entre marcar o nó como condição desconhecida (ConditionUnknown) e enviar a primeira solicitação de remoção.

O controlador de nó verifica o estado de cada nó a cada --node-monitor-period segundos.

Limites de taxa de remoção

Na maioria dos casos, o controlador de nós limita a taxa de remoção a --node-eviction-rate (0,1 por padrão) por segundo, o que significa que ele não removerá pods de mais de 1 nó por 10 segundos.

O comportamento de remoção do nó muda quando um nó em uma determinada zona de disponibilidade se torna não íntegro. O controlador de nós verifica qual porcentagem de nós na zona não são íntegras (a condição NodeReady é desconhecida ConditionUnknown ou falsa ConditionFalse) ao mesmo tempo:

• Se a fração de nós não íntegros for ao menos --unhealthy-zone-threshold (padrão 0,55), então a taxa de remoção será reduzida.
• Se o cluster for pequeno (ou seja, tiver número de nós menor ou igual ao valor da opção --large-cluster-size-threshold - padrão 50), então as remoções serão interrompidas.
• Caso contrário, a taxa de remoção é reduzida para --secondary-node-eviction-rate de nós secundários (padrão 0,01) por segundo.

A razão pela qual essas políticas são implementadas por zona de disponibilidade é porque a camada de gerenciamento pode perder conexão com uma zona de disponibilidade, enquanto as outras permanecem conectadas. Se o seu cluster não abranger várias zonas de disponibilidade de provedores de nuvem, o mecanismo de remoção não levará em conta a indisponibilidade por zona.

Uma das principais razões para espalhar seus nós pelas zonas de disponibilidade é para que a carga de trabalho possa ser transferida para zonas íntegras quando uma zona inteira cair. Portanto, se todos os nós em uma zona não estiverem íntegros, o controlador do nó removerá na taxa normal de --node-eviction-rate. O caso especial é quando todas as zonas estiverem completamente insalubres (nenhum dos nós do cluster será íntegro). Nesse caso, o controlador do nó assume que há algum problema com a conectividade entre a camada de gerenciamento e os nós e não realizará nenhuma remoção. (Se houver uma interrupção e alguns nós reaparecerem, o controlador do nó expulsará os pods dos nós restantes que estiverem insalubres ou inacessíveis).

O controlador de nós também é responsável por remover pods em execução nos nós com NoExecute taints, a menos que esses pods tolerem essa taint. O controlador de nó também adiciona as taints correspondentes aos problemas de nó, como nó inacessível ou não pronto. Isso significa que o escalonador não colocará Pods em nós não íntegros.

Rastreamento de capacidade de recursos

Os objetos do nó rastreiam informações sobre a capacidade de recursos do nó: por exemplo, a quantidade de memória disponível e o número de CPUs. Os nós que se auto-registram relatam sua capacidade durante o registro. Se você adicionar manualmente um nó, precisará definir as informações de capacidade do nó ao adicioná-lo.

O escalonador do Kubernetes garante que haja recursos suficientes para todos os Pods em um nó. O escalonador verifica se a soma das solicitações de contêineres no nó não é maior do que a capacidade do nó. Essa soma de solicitações inclui todos os contêineres gerenciados pelo kubelet, mas exclui quaisquer contêineres iniciados diretamente pelo agente de execução de contêiner e também exclui quaisquer processos executados fora do controle do kubelet.

Topologia do Nó

Se você ativou os [recursos]](/docs/reference/command-line-tools-reference/feature-gates/) de TopologyManager, o kubelet pode usar dicas da topologia ao tomar decisões de atribuição de recursos. Consulte Controle das Políticas de Gerenciamento de Topologia em um Nó para obter mais informações.

Desligamento gracioso do nó

O kubelet tenta detectar o desligamento do sistema do nó e encerra os pods em execução no nó.

O Kubelet garante que os pods sigam o processo normal de término do podpod-lifecycle/#pod-termination) durante o desligamento do nó.

O recurso de desligamento gradual do nó depende do systemd, pois aproveita os bloqueios do inibidor do systemd para atrasar o desligamento do nó com uma determinada duração.

O desligamento gradual do nó é controlado com recursos GracefulNodeShutdown, que é ativado por padrão na versão 1.21.

Observe que, por padrão, ambas as opções de configuração descritas abaixo, shutdownGracePeriod and shutdownGracePeriodCriticalPods estão definidas como zero, não ativando assim a funcionalidade de desligamento gradual do nó. Para ativar o recurso, as duas configurações do kubelet devem ser configuradas adequadamente e definidas como valores diferentes de zero.

Durante um desligamento gradual, o kubelet encerra os pods em duas fases:

1. Encerra os pods regulares em execução no nó.
2. Encerra os pods críticos em execução no nó.

O recurso de desligamento gradual do nó é configurado com duas opções KubeletConfiguration:

• shutdownGracePeriod:

  • Especifica a duração total pela qual o nó deve atrasar o desligamento. Este é o período de carência total para o término dos pods regulares e os críticos.

• shutdownGracePeriodCriticalPods:

  • Especifica a duração utlizada para encerrar pods críticos durante um desligamento de nó. Este valor deve ser menor que shutdownGracePeriod.

Por exemplo, se shutdownGracePeriod=30s e shutdownGracePeriodCriticalPods=10s, o kubelet atrasará o desligamento do nó em 30 segundos. Durante o desligamento, os primeiros 20 (30-10) segundos seriam reservados para encerrar gradualmente os pods normais, e os últimos 10 segundos seriam reservados para encerrar pods críticos.

Reason:         Terminated
Message:        Pod was terminated in response to imminent node shutdown.

Desligamento gradual do nó baseado em prioridade do Pod

Para fornecer mais flexibilidade durante o desligamento gradual do nó em torno da ordem de pods durante o desligamento, o desligamento gradual do nó respeita a PriorityClass dos Pods, desde que você tenha ativado esse recurso em seu cluster. O recurso permite que o cluster defina explicitamente a ordem dos pods durante o desligamento gradual do nó com base em classes de prioridade.

O recurso Desligamento Gradual do Nó, conforme descrito acima, desliga pods em duas fases, pods não críticos, seguidos por pods críticos. Se for necessária flexibilidade adicional para definir explicitamente a ordem dos pods durante o desligamento de uma maneira mais granular, o desligamento gradual baseado na prioridade do pod pode ser usado.

Quando o desligamento gradual do nó respeita as prioridades do pod, isso torna possível fazer o desligamento gradual do nó em várias fases, cada fase encerrando uma classe de prioridade específica de pods. O kubelet pode ser configurado com as fases exatas e o tempo de desligamento por fase.

Assumindo as seguintes classes de prioridade de pod personalizadas em um cluster,

Na configuração do kubelet, as configurações para shutdownGracePeriodByPodPriority são semelhantes a:

A configuração correspondente do YAML do kubelet seria:

shutdownGracePeriodByPodPriority:
  - priority: 100000
    shutdownGracePeriodSeconds: 10
  - priority: 10000
    shutdownGracePeriodSeconds: 180
  - priority: 1000
    shutdownGracePeriodSeconds: 120
  - priority: 0
    shutdownGracePeriodSeconds: 60

A tabela acima implica que qualquer pod com valor priority >= 100000 terá apenas 10 segundos para parar qualquer pod com valor >= 10000 e < 100000 e terá 180 segundos para parar, qualquer pod com valor >= 1000 e < 10000 terá 120 segundos para parar. Finalmente, todos os outros pods terão 60 segundos para parar.

Não é preciso especificar valores correspondentes para todas as classes. Por exemplo, você pode usar estas configurações:

No caso acima, os pods com custom-class-b irão para o mesmo bucket que custom-class-c para desligamento.

Se não houver pods em um intervalo específico, o kubelet não irá espera por pods nesse intervalo de prioridades. Em vez disso, o kubelet pula imediatamente para o próximo intervalo de valores da classe de prioridade.

Se esse recurso estiver ativado e nenhuma configuração for fornecida, nenhuma ação de pedido será tomada.

O uso desse recurso requer ativar os recursos GracefulNodeShutdownBasedOnPodPriority e definir o ShutdownGracePeriodByPodPriority da configuração do kubelet para a configuração desejada, contendo os valores da classe de prioridade do pod e seus respectivos períodos de desligamento.

Gerenciamento da memória swap

Antes do Kubernetes 1.22, os nós não suportavam o uso de memória swap, e um kubelet, por padrão, não iniciaria se a troca fosse detectada em um nó. A partir de 1.22, o suporte a memória swap pode ser ativado por nó.

Para ativar a troca em um nó, o recursos NodeSwap deve estar ativado no kubelet, e a configuração de comando de linha --fail-swap-on ou failSwapOn deve ser definida como falsa.

Opcionalmente, um usuário também pode configurar memorySwap.swapBehavior para especificar como um nó usará memória swap. Por exemplo,

memorySwap:
  swapBehavior: LimitedSwap

As opções de configuração disponíveis para swapBehavior são:

• LimitedSwap: As cargas de trabalho do Kubernetes são limitadas na quantidade de troca que podem usar. Cargas de trabalho no nó não gerenciadas pelo Kubernetes ainda podem ser trocadas.
• UnlimitedSwap: As cargas de trabalho do Kubernetes podem usar tanta memória de swap quanto solicitarem, até o limite do sistema.

Se a configuração do memorySwap não for especificada e o recurso estiver ativado, por padrão, o kubelet aplicará o mesmo comportamento que a configuração LimitedSwap.

O comportamento da configuração LimitedSwap depende se o nó estiver sendo executado com v1 ou v2 de grupos de controle (também conhecidos como "cgroups"):

• cgroupsv1: As cargas de trabalho do Kubernetes podem usar qualquer combinação de memória e swap, até o limite de memória do pod, se definido.
• cgroupsv2: As cargas de trabalho do Kubernetes não podem usar memória swap.

Para obter mais informações e para ajudar nos testes e fornecer feedback, consulte KEP-2400 e sua proposta de design.

Próximos passos

• Saiba mais sobre componentes que compõem um nó.
• Leia a definição da API para um Nó.
• Leia a seção Nó do documento de design de arquitetura.
• Leia sobre taints e tolerâncias.

4.2 - Comunicação entre Nós e a Camada de Gerenciamento

Este documento cataloga os caminhos de comunicação entre o servidor de API e o cluster Kubernetes. A intenção é permitir que os usuários personalizem sua instalação para endurecer a configuração de rede de tal forma que o cluster pode ser executado em uma rede não confiável (ou em IPs totalmente públicos em um provedor de nuvem).

Nó para a Camada de Gerenciamento

O Kubernetes tem um padrão de API "hub-and-spoke". Todo uso da API dos nós (ou dos pods que eles executam) termina no servidor de API. Nenhum dos outros componentes da camada de gerenciamento são projetados para expor serviços remotos. O servidor de API é configurado para escutar conexões remotas em uma porta HTTPS segura (tipicamente 443) com uma ou mais formas de autenticação de cliente habilitada. Uma ou mais formas de autorização devem ser habilitadas, especialmente se requisições anônimas ou tokens da conta de serviço são permitidos.

Os nós devem ser provisionados com o certificado raiz público do cluster de tal forma que eles podem se conectar de forma segura ao servidor de API junto com credenciais de cliente válidas. Uma boa abordagem é que as credenciais de cliente fornecidas ao kubelet estejam na forma de um certificado de cliente. Veja inicialização TLS do kubelet para provisionamento automatizado de certificados de cliente do kubelet.

Pods que desejam se conectar ao servidor de API podem fazê-lo com segurança, aproveitando uma conta de serviço para que o Kubernetes injete automaticamente o certificado raiz público e um token de portador válido no pod quando ele for instanciado. O serviço kubernetes (no namespace default) é configurado com um endereço IP virtual que é redirecionado (via kube-proxy) para o endpoint HTTPS no servidor de API.

Os componentes da camada de gerenciamento também se comunicam com o servidor de API através da porta segura.

Como resultado, o modo de operação padrão para conexões dos nós e dos pods em execução nos nós para a camada de gerenciamento é seguro por padrão e pode operar em redes não confiáveis e/ou públicas.

Camada de Gerenciamento para o Nó

Existem dois caminhos de comunicação primários da camada de gerenciamento (o servidor de API) para os nós. O primeiro é do servidor de API para o processo kubelet que executa em cada nó no cluster. O segundo é do servidor de API para qualquer nó, pod, ou serviço através da funcionalidade de proxy do servidor de API.

Servidor de API para o kubelet

As conexões do servidor de API para o kubelet são usadas para:

• Buscar logs para pods.
• Conectar-se (geralmente através de kubectl) a pods em execução.
• Fornecer a funcionalidade de encaminhamento de porta do kubelet.

Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão, o servidor de API não verifica o certificado de serviço do kubelet, o que torna a conexão sujeita a ataques man-in-the-middle e insegura para executar por redes não confiáveis e/ou públicas.

Para verificar essa conexão, use a flag --kubelet-certificate-authority para fornecer ao servidor de API um pacote de certificado raiz para usar e verificar o certificado de serviço do kubelet.

Se isso não for possível, use túneis SSH entre o servidor de API e kubelet se necessário para evitar conectar por uma rede não confiável ou pública.

Finalmente, Autenticação e/ou autorização do Kubelet deve ser habilitada para proteger a API do kubelet.

Servidor de API para nós, pods e serviços

As conexões do servidor de API com um nó, pod, ou serviço são conexões HTTP simples por padrão e, portanto, não são autenticadas nem criptografadas. Elas podem ser executadas por uma conexão HTTPS segura prefixando https: ao nome do nó, pod, ou serviço na URL da API, mas elas não validarão o certificado fornecido pelo endpoint HTTPS nem fornecerão credenciais de cliente. Então enquanto a conexão será criptografada, ela não fornecerá nenhuma garantia de integridade. Essas conexões não são atualmente seguras para executar por redes não confiáveis e/ou públicas.

Túneis SSH

O Kubernetes suporta túneis SSH para proteger os caminhos de comunicação da camada de gerenciamento para os nós. Nesta configuração, o servidor de API inicia um túnel SSH para cada nó no cluster (conectando ao servidor SSH escutando na porta 22) e passa todo o tráfego destinado a um kubelet, nó, pod, ou serviço através do túnel. Este túnel garante que o tráfego não seja exposto fora da rede na qual os nós estão executando.

Serviço Konnectivity

Como um substituto aos túneis SSH, o serviço Konnectivity fornece proxy de nível TCP para a comunicação da camada de gerenciamento para o cluster. O serviço Konnectivity consiste em duas partes: o servidor Konnectivity na rede da camada de gerenciamento e os agentes Konnectivity na rede dos nós. Os agentes Konnectivity iniciam conexões com o servidor Konnectivity e mantêm as conexões de rede. Após habilitar o serviço Konnectivity, todo o tráfego da camada de gerenciamento para os nós passa por essas conexões.

Siga a tarefa do serviço Konnectivity para configurar o serviço Konnectivity no seu cluster.

Próximos passos

• Leia sobre os componentes da camada de gerenciamento do Kubernetes
• Saiba mais sobre o modelo Hubs and Spoke
• Aprenda como Proteger um Cluster
• Saiba mais sobre a API do Kubernetes
• Configurar o serviço Konnectivity
• Usar Encaminhamento de Porta para Acessar Aplicações em um Cluster
• Aprenda como Buscar logs para Pods, usar kubectl port-forward

4.3 - Conceitos sobre Cloud Controller Manager

O conceito do Cloud Controller Manager (CCM) (não confundir com o binário) foi originalmente criado para permitir que o código específico de provedor de nuvem e o núcleo do Kubernetes evoluíssem independentemente um do outro. O Cloud Controller Manager é executado junto com outros componentes principais, como o Kubernetes controller manager, o servidor de API e o scheduler. Também pode ser iniciado como um addon do Kubernetes, caso em que é executado em cima do Kubernetes.

O design do Cloud Controller Manager é baseado em um mecanismo de plug-in que permite que novos provedores de nuvem se integrem facilmente ao Kubernetes usando plug-ins. Existem planos para integrar novos provedores de nuvem no Kubernetes e para migrar provedores de nuvem que estão utilizando o modelo antigo para o novo modelo de CCM.

Este documento discute os conceitos por trás do Cloud Controller Manager e fornece detalhes sobre suas funções associadas.

Aqui está a arquitetura de um cluster Kubernetes sem o Cloud Controller Manager:

Projeto de Arquitetura (Design)

No diagrama anterior, o Kubernetes e o provedor de nuvem são integrados através de vários componentes diferentes:

• Kubelet
• Kubernetes controller manager
• Kubernetes API server

O CCM consolida toda a lógica que depende da nuvem dos três componentes anteriores para criar um único ponto de integração com a nuvem. A nova arquitetura com o CCM se parece com isso:

Componentes do CCM

O CCM separa algumas das funcionalidades do KCM (Kubernetes Controller Manager) e o executa como um processo separado. Especificamente, isso elimina os controladores no KCM que dependem da nuvem. O KCM tem os seguintes loops de controlador dependentes de nuvem:

• Node controller
• Volume controller
• Route controller
• Service controller

Na versão 1.9, o CCM executa os seguintes controladores da lista anterior:

• Node controller
• Route controller
• Service controller

O plano original para suportar volumes usando o CCM era usar volumes Flex para suportar volumes plugáveis. No entanto, um esforço concorrente conhecido como CSI está sendo planejado para substituir o Flex.

Considerando essas dinâmicas, decidimos ter uma medida de intervalo intermediário até que o CSI esteja pronto.

Funções do CCM

O CCM herda suas funções de componentes do Kubernetes que são dependentes de um provedor de nuvem. Esta seção é estruturada com base nesses componentes.

1. Kubernetes Controller Manager

A maioria das funções do CCM é derivada do KCM. Conforme mencionado na seção anterior, o CCM executa os seguintes ciclos de controle:

• Node Controller
• Route Controller
• Service Controller

Node Controller

O Node Controller é responsável por inicializar um nó obtendo informações sobre os nós em execução no cluster do provedor de nuvem. O Node Controller executa as seguintes funções:

1. Inicializar um node com labels de região/zona específicos para a nuvem.
2. Inicialize um node com detalhes de instância específicos da nuvem, por exemplo, tipo e tamanho.
3. Obtenha os endereços de rede e o nome do host do node.
4. No caso de um node não responder, verifique a nuvem para ver se o node foi excluído da nuvem. Se o node foi excluído da nuvem, exclua o objeto Node do Kubernetes.

Route Controller

O Route Controller é responsável por configurar as rotas na nuvem apropriadamente, de modo que os contêineres em diferentes nodes no cluster do Kubernetes possam se comunicar entre si. O Route Controller é aplicável apenas para clusters do Google Compute Engine.

Service controller

O Service controller é responsável por ouvir os eventos de criação, atualização e exclusão do serviço. Com base no estado atual dos serviços no Kubernetes, ele configura os balanceadores de carga da nuvem (como o ELB, o Google LB ou o Oracle Cloud Infrastrucutre LB) para refletir o estado dos serviços no Kubernetes. Além disso, garante que os back-ends de serviço para balanceadores de carga da nuvem estejam atualizados.

2. Kubelet

O Node Controller contém a funcionalidade dependente da nuvem do kubelet. Antes da introdução do CCM, o kubelet era responsável por inicializar um nó com detalhes específicos da nuvem, como endereços IP, rótulos de região / zona e informações de tipo de instância. A introdução do CCM mudou esta operação de inicialização do kubelet para o CCM.

Nesse novo modelo, o kubelet inicializa um nó sem informações específicas da nuvem. No entanto, ele adiciona uma marca (taint) ao nó recém-criado que torna o nó não programável até que o CCM inicialize o nó com informações específicas da nuvem. Em seguida, remove essa mancha (taint).

Mecanismo de plugins

O Cloud Controller Manager usa interfaces Go para permitir implementações de qualquer nuvem a ser conectada. Especificamente, ele usa a Interface CloudProvider definidaaqui.

A implementação dos quatro controladores compartilhados destacados acima, e algumas estruturas que ficam junto com a interface compartilhada do provedor de nuvem, permanecerão no núcleo do Kubernetes. Implementações específicas para provedores de nuvem serão construídas fora do núcleo e implementarão interfaces definidas no núcleo.

Para obter mais informações sobre o desenvolvimento de plug-ins, consulteDesenvolvendo o Cloud Controller Manager.

Autorização

Esta seção divide o acesso necessário em vários objetos da API pelo CCM para executar suas operações.

Node Controller

O Node Controller só funciona com objetos Node. Ele requer acesso total para obter, listar, criar, atualizar, corrigir, assistir e excluir objetos Node.

v1/Node:

• Get
• List
• Create
• Update
• Patch
• Watch
• Delete

Rote Controller

O Rote Controller escuta a criação do objeto Node e configura as rotas apropriadamente. Isso requer acesso a objetos Node.

v1/Node:

• Get

Service Controller

O Service Controller escuta eventos de criação, atualização e exclusão de objeto de serviço e, em seguida, configura pontos de extremidade para esses serviços de forma apropriada.

Para acessar os Serviços, é necessário listar e monitorar o acesso. Para atualizar os Serviços, ele requer patch e atualização de acesso.

Para configurar endpoints para os Serviços, é necessário acesso para criar, listar, obter, assistir e atualizar.

v1/Service:

• List
• Get
• Watch
• Patch
• Update

Outros

A implementação do núcleo do CCM requer acesso para criar eventos e, para garantir a operação segura, requer acesso para criar ServiceAccounts.

v1/Event:

• Create
• Patch
• Update

v1/ServiceAccount:

• Create

O RBAC ClusterRole para o CCM se parece com isso:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - get
  - list
  - watch
  - update

Implementações de Provedores de Nuvem

Os seguintes provedores de nuvem implementaram CCMs:

• Digital Ocean
• Oracle
• Azure
• GCP
• AWS
• BaiduCloud
• Linode

Administração de Cluster

Você vai encontrar instruções completas para configurar e executar o CCM aqui.

4.4 - Controladores

Em robótica e automação um control loop, ou em português ciclo de controle, é um ciclo não terminado que regula o estado de um sistema.

Aqui está um exemplo de um ciclo de controle: um termostato em uma sala.

Quando você define a temperatura, isso indica ao termostato sobre o seu estado desejado. A temperatura ambiente real é o estado atual. O termostato atua para trazer o estado atual mais perto do estado desejado, ligando ou desligando o equipamento.

Padrão Controlador

Um controlador rastreia pelo menos um tipo de recurso Kubernetes. Estes objetos têm um campo spec que representa o estado desejado. O(s) controlador(es) para aquele recurso são responsáveis por fazer o estado atual se aproximar daquele estado desejado.

O controlador pode executar a ação ele próprio; mais comumente, no Kubernetes, um controlador enviará mensagens para o servidor de API que têm efeitos colaterais úteis. Você verá exemplos disso abaixo.

Controle via servidor de API

O controlador Job é um exemplo de um controlador embutido do Kubernetes. Controladores embutidos gerenciam estado através da interação com o servidor de API do cluster.

Job é um recurso do Kubernetes que executa um Pod, ou talvez vários Pods, para realizar uma tarefa e depois parar.

(Uma vez agendado, objetos Pod se tornam parte do estado desejado para um kubelet).

Quando o controlador Job vê uma nova tarefa, ele garante que, em algum lugar no seu cluster, os kubelets em um conjunto de Nodes estão executando o número correto de Pods para realizar o trabalho. O controlador Job não executa nenhum Pod ou contêiner ele próprio. Em vez disso, o controlador Job informa o servidor de API para criar ou remover Pods. Outros componentes no camada de gerenciamento atuam na nova informação (existem novos Pods para serem agendados e executados), e eventualmente o trabalho é feito.

Após criar um novo Job, o estado desejado é que esse Job seja completado. O controlador Job faz com que o estado atual para esse Job esteja mais próximo do seu estado desejado: criando Pods que fazem o trabalho que você queria para esse Job, para que o Job esteja mais próximo da conclusão.

Controladores também atualizam os objetos que os configuram. Por exemplo: uma vez que o trabalho de um Job está completo, o controlador Job atualiza esse objeto Job para marcá-lo como Finished.

(Isso é um pouco como alguns termostatos desligam uma luz para indicar que a sala está agora na temperatura que você definiu).

Controle direto

Em contraste com Job, alguns controladores precisam fazer mudanças em coisas fora do seu cluster.

Por exemplo, se você usar um ciclo de controle para garantir que existem Nodes suficientes no seu cluster, então esse controlador precisa de algo fora do cluster atual para configurar novos Nodes quando necessário.

Controladores que interagem com estado externo encontram seu estado desejado a partir do servidor de API, então comunicam diretamente com um sistema externo para trazer o estado atual mais próximo da linha.

(Existe na verdade um controlador que escala horizontalmente os nodes no seu cluster.)

O ponto importante aqui é que o controlador faz algumas mudanças para trazer seu estado desejado, e então relata o estado atual de volta ao servidor de API do seu cluster. Outros ciclos de controle podem observar esses dados relatados e tomar suas próprias ações.

No exemplo do termostato, se a sala estiver muito fria, então um controlador diferente pode também ligar um aquecedor de proteção contra geada. Com clusters Kubernetes, a camada de gerenciamento indiretamente trabalha com ferramentas de gerenciamento de endereços IP, serviços de armazenamento, APIs de provedores de nuvem, e outros serviços através de estender o Kubernetes para implementar isso.

Estado desejado versus atual

O Kubernetes tem uma visão cloud-native de sistemas, e é capaz de lidar com mudanças constantes.

Seu cluster pode estar mudando a qualquer momento conforme o trabalho acontece e ciclos de controle corrigem falhas automaticamente. Isso significa que, potencialmente, seu cluster nunca atinge um estado estável.

Enquanto os controladores do seu cluster estiverem executando e forem capazes de fazer mudanças úteis, não importa se o estado geral é estável ou não.

Design

Como um princípio do seu design, o Kubernetes usa muitos controladores que cada um gerencia um aspecto particular do estado do cluster. Mais comumente, um ciclo de controle particular (controlador) usa um tipo de recurso como seu estado desejado, e tem um tipo diferente de recurso que ele gerencia para fazer esse estado desejado acontecer. Por exemplo, um controlador para Jobs rastreia objetos Job (para descobrir novo trabalho) e objetos Pod (para executar os Jobs, e então ver quando o trabalho termina). Neste caso algo mais cria os Jobs, enquanto o controlador Job cria Pods.

É útil ter controladores simples em vez de um conjunto monolítico de ciclos de controle que estão interligados. Controladores podem falhar, então o Kubernetes foi projetado para permitir isso.

Formas de executar controladores

O Kubernetes vem com um conjunto de controladores embutidos que executam dentro do kube-controller-manager. Estes controladores embutidos fornecem comportamentos centrais importantes.

O controlador Deployment e o controlador Job são exemplos de controladores que vêm como parte do próprio Kubernetes (controladores "embutidos"). O Kubernetes permite que você execute uma camada de gerenciamento resiliente, para que se qualquer um dos controladores embutidos falhar, outra parte da camada de gerenciamento assumirá o trabalho.

Você pode encontrar controladores que executam fora da camada de gerenciamento, para estender o Kubernetes. Ou, se quiser, pode escrever um novo controlador você mesmo. Você pode executar seu próprio controlador como um conjunto de Pods, ou externamente ao Kubernetes. O que se encaixa melhor dependerá do que esse controlador particular faz.

Próximos passos

• Leia sobre a camada de gerenciamento do Kubernetes
• Descubra alguns dos objetos Kubernetes básicos
• Saiba mais sobre a API do Kubernetes
• Se quiser escrever seu próprio controlador, veja padrões de extensão do Kubernetes e o repositório sample-controller

4.5 - Coleta de Lixo

Coleta de lixo (Garbage collection) é um termo coletivo para os vários mecanismos que o Kubernetes usa para limpar os recursos do cluster. Isso permite a limpeza de recursos como os seguintes:

• Pods terminados
• Jobs completados
• Objetos sem referências de proprietário
• Contêineres e imagens de contêiner não utilizados
• PersistentVolumes provisionados dinamicamente com uma política de recuperação de StorageClass de Delete
• CertificateSigningRequests (CSRs) obsoletos ou expirados
• Nodes excluídos nos seguintes cenários:
  • Na nuvem quando o cluster usa um gerenciador de controlador de nuvem
  • On-premises quando o cluster usa um addon similar a um gerenciador de controlador de nuvem
• Objetos Node Lease

Proprietários e dependentes

Muitos objetos no Kubernetes se vinculam uns aos outros através de referências de proprietário. As referências de proprietário informam à camada de gerenciamento quais objetos são dependentes de outros. O Kubernetes usa referências de proprietário para dar à camada de gerenciamento, e outros clientes da API, a oportunidade de limpar recursos relacionados antes de excluir um objeto. Na maioria dos casos, o Kubernetes gerencia referências de proprietário automaticamente.

A propriedade é diferente do mecanismo de labels e seletores que alguns recursos também usam. Por exemplo, considere um Service que cria objetos EndpointSlice. O Service usa labels para permitir que a camada de gerenciamento determine quais objetos EndpointSlice são usados para esse Service. Além das labels, cada EndpointSlice que é gerenciado em nome de um Service tem uma referência de proprietário. As referências de proprietário ajudam diferentes partes do Kubernetes a evitar interferir com objetos que elas não controlam.

Exclusão em cascata

O Kubernetes verifica e exclui objetos que não têm mais referências de proprietário, como os Pods deixados para trás quando você exclui um ReplicaSet. Quando você exclui um objeto, pode controlar se o Kubernetes exclui os dependentes do objeto automaticamente, em um processo chamado exclusão em cascata. Existem dois tipos de exclusão em cascata, como segue:

• Exclusão em cascata em primeiro plano
• Exclusão em cascata em segundo plano

Você também pode controlar como e quando a coleta de lixo exclui recursos que têm referências de proprietário usando finalizadores do Kubernetes.

Exclusão em cascata em primeiro plano

Na exclusão em cascata em primeiro plano, o objeto proprietário que você está excluindo primeiro entra em um estado de exclusão em progresso. Neste estado, o seguinte acontece com o objeto proprietário:

• O servidor de API do Kubernetes define o campo metadata.deletionTimestamp do objeto para o momento em que o objeto foi marcado para exclusão.
• O servidor de API do Kubernetes também define o campo metadata.finalizers para foregroundDeletion.
• O objeto permanece visível através da API do Kubernetes até que o processo de exclusão seja concluído.

Depois que o objeto proprietário entra no estado de exclusão em progresso, o controlador exclui dependentes que conhece. Após excluir todos os objetos dependentes que conhece, o controlador exclui o objeto proprietário. Neste ponto, o objeto não é mais visível na API do Kubernetes.

Durante a exclusão em cascata em primeiro plano, os únicos dependentes que bloqueiam a exclusão do proprietário são aqueles que têm o campo ownerReference.blockOwnerDeletion=true e estão no cache do controlador de coleta de lixo. O cache do controlador de coleta de lixo pode não conter objetos cujo tipo de recurso não pode ser listado/observado com sucesso, ou objetos que são criados simultaneamente com a exclusão de um objeto proprietário. Veja Usar exclusão em cascata em primeiro plano para saber mais.

Exclusão em cascata em segundo plano

Na exclusão em cascata em segundo plano, o servidor de API do Kubernetes exclui o objeto proprietário imediatamente e o controlador de coleta de lixo (personalizado ou padrão) limpa os objetos dependentes em segundo plano. Se um finalizador existir, ele garante que os objetos não sejam excluídos até que todas as tarefas de limpeza necessárias sejam concluídas. Por padrão, o Kubernetes usa exclusão em cascata em segundo plano, a menos que você use manualmente a exclusão em primeiro plano ou escolha tornar órfãos os objetos dependentes.

Veja Usar exclusão em cascata em segundo plano para saber mais.

Dependentes órfãos

Quando o Kubernetes exclui um objeto proprietário, os dependentes deixados para trás são chamados de objetos órfãos. Por padrão, o Kubernetes exclui objetos dependentes. Para aprender como sobrescrever este comportamento, veja Excluir objetos proprietários e tornar órfãos os dependentes.

Coleta de lixo de contêineres e imagens não utilizados

O kubelet executa coleta de lixo em imagens não utilizadas a cada cinco minutos e em contêineres não utilizados a cada minuto. Você deve evitar usar ferramentas externas de coleta de lixo, pois estas podem quebrar o comportamento do kubelet e remover contêineres que deveriam existir.

Para configurar opções para coleta de lixo de contêineres e imagens não utilizados, ajuste o kubelet usando um arquivo de configuração e altere os parâmetros relacionados à coleta de lixo usando o tipo de recurso KubeletConfiguration.

Ciclo de vida da imagem de contêiner

O Kubernetes gerencia o ciclo de vida de todas as imagens através do seu gerenciador de imagens, que é parte do kubelet, com a cooperação do cadvisor. O kubelet considera os seguintes limites de uso de disco ao tomar decisões de coleta de lixo:

• HighThresholdPercent
• LowThresholdPercent

O uso de disco acima do valor HighThresholdPercent configurado aciona a coleta de lixo, que exclui imagens em ordem baseada na última vez que foram usadas, começando com a mais antiga primeiro. O kubelet exclui imagens até que o uso de disco atinja o valor LowThresholdPercent.

Coleta de lixo para imagens de contêiner não utilizadas

Como uma funcionalidade beta, você pode especificar o tempo máximo que uma imagem local pode ficar não utilizada, independentemente do uso de disco. Esta é uma configuração do kubelet que você configura para cada node.

Para configurar a definição, você precisa definir um valor para o campo imageMaximumGCAge no arquivo de configuração do kubelet.

O valor é especificado como uma duração do Kubernetes. Veja duração no glossário para mais detalhes.

Por exemplo, você pode definir o campo de configuração para 12h45m, o que significa 12 horas e 45 minutos.

Coleta de lixo de contêineres

O kubelet coleta lixo de contêineres não utilizados baseado nas seguintes variáveis, que você pode definir:

• MinAge: a idade mínima na qual o kubelet pode coletar lixo de um contêiner. Desabilite definindo como 0.
• MaxPerPodContainer: o número máximo de contêineres mortos que cada Pod pode ter. Desabilite definindo como menor que 0.
• MaxContainers: o número máximo de contêineres mortos que o cluster pode ter. Desabilite definindo como menor que 0.

Além dessas variáveis, o kubelet coleta lixo de containers não identificados e excluídos, tipicamente começando com o mais antigo primeiro.

MaxPerPodContainer e MaxContainers podem potencialmente entrar em conflito um com o outro em situações onde manter o número máximo de contêineres por Pod (MaxPerPodContainer) iria além do total permitido de contêineres mortos globais (MaxContainers). Nesta situação, o kubelet ajusta MaxPerPodContainer para resolver o conflito. Um cenário de pior caso seria rebaixar MaxPerPodContainer para 1 e despejar os containers mais antigos. Adicionalmente, contêineres pertencentes a Pods que foram excluídos são removidos uma vez que são mais antigos que MinAge.

Configurando coleta de lixo

Você pode ajustar a coleta de lixo de recursos configurando opções específicas para os controladores que gerenciam esses recursos. As seguintes páginas mostram como configurar coleta de lixo:

• Configurando exclusão em cascata de objetos Kubernetes
• Configurando limpeza de Jobs finalizados

Próximos passos

• Saiba mais sobre propriedade de objetos Kubernetes.
• Saiba mais sobre finalizadores do Kubernetes.
• Saiba sobre o controlador TTL que limpa Jobs finalizados.

5 - Contêineres

Cada contêiner executado é repetível; a padronização de ter dependências incluídas significa que você obtém o mesmo comportamento onde quer que você execute.

Os contêineres separam os aplicativos da infraestrutura de host subjacente. Isso torna a implantação mais fácil em diferentes ambientes de nuvem ou sistema operacional.

Imagem de contêiner

Uma imagem de contêiner é um pacote de software pronto para executar, contendo tudo que é preciso para executar uma aplicação: o código e o agente de execução necessário, aplicação, bibliotecas do sistema e valores padrões para qualquer configuração essencial.

Por design, um contêiner é imutável: você não pode mudar o código de um contêiner que já está executando. Se você tem uma aplicação conteinerizada e quer fazer mudanças, você precisa construir uma nova imagem que inclui a mudança, e recriar o contêiner para iniciar a partir da imagem atualizada.

Agente de execução de contêiner

O agente de execução (runtime) de contêiner é o software responsável por executar os contêineres.

O Kubernetes suporta diversos agentes de execução de contêineres: Docker, containerd, CRI-O, e qualquer implementação do Kubernetes CRI (Container Runtime Interface).

Próximos passos

• Imagens de contêineres
• Pods

5.1 - Imagens

Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente.

Normalmente, você cria uma imagem de contêiner da sua aplicação e a envia para um registro antes de fazer referência a ela em um Pod.

Esta página fornece um resumo sobre o conceito de imagem de contêiner.

Nomes das imagens

As imagens de contêiner geralmente recebem um nome como pause, exemplo/meuconteiner, ou kube-apiserver. As imagens também podem incluir um hostname de algum registro; por exemplo: exemplo.registro.ficticio/nomeimagem, e um possível número de porta; por exemplo: exemplo.registro.ficticio:10443/nomeimagem.

Se você não especificar um nome de host do registro, o Kubernetes assume que você está se referindo ao registro público do Docker. Você pode alterar esse comportamento definindo um registro de imagem padrão na configuração do agente de execução do contêiner.

Após a parte do nome da imagem, você pode adicionar uma tag ou digest (da mesma forma que faria ao usar comandos como docker ou podman). As tags permitem identificar diferentes versões da mesma série de imagens. Digests são identificadores únicos para uma versão específica de uma imagem. Digests são hashes do conteúdo da imagem e são imutáveis. As tags podem ser movidas para apontar para imagens diferentes, mas os digests são fixos.

Tags de imagem consistem em letras minúsculas e maiúsculas, dígitos, sublinhados (_), pontos (.) e hifens (-). Elas podem ter até 128 caracteres de comprimento e devem seguir o seguinte padrão de expressão regular: [a-zA-Z0-9_][a-zA-Z0-9._-]{0,127}. Você pode ler mais sobre e encontrar a expressão regular de validação na Especificação de Distribuição OCI. Se você não especificar uma tag, o Kubernetes assume que você está se referindo à tag latest.

Digests de imagem consistem em um algoritmo de hash (como sha256) e um valor de hash. Por exemplo: sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07. Você pode encontrar mais informações sobre o formato de digests na Especificação de Imagem OCI.

Alguns exemplos de nomes de imagem que o Kubernetes pode usar são:

• busybox - Nome da imagem apenas, sem tag ou digest. O Kubernetes usará o registro público do Docker e a tag latest. (Equivalente a docker.io/library/busybox:latest)
• busybox:1.32.0 - Nome da imagem com tag. O Kubernetes usará o registro público do Docker. (Equivalente a docker.io/library/busybox:1.32.0)
• registry.k8s.io/pause:latest - Nome da imagem com um registro personalizado e tag latest.
• registry.k8s.io/pause:3.5 - Nome da imagem com um registro personalizado e tag diferente de latest.
• registry.k8s.io/pause@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07 - Nome da imagem com digest.
• registry.k8s.io/pause:3.5@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07 - Nome da imagem com tag e digest. Apenas o digest será usado para o download.

Atualizando imagens

Quando você cria um Deployment, StatefulSet, Pod ou outro objeto que inclua um template de Pod, por padrão a política utilizada para baixar as imagens dos contêineres nesse Pod será definida como IfNotPresent quando não especificada explicitamente. Essa política faz com que o kubelet ignore o download da imagem se ela já existir.

Política de download de imagem

A imagePullPolicy de um contêiner e a tag da imagem afetam quando o kubelet tenta puxar (download) a imagem especificada.

Aqui está uma lista dos valores que você pode definir para imagePullPolicy e os efeitos que esses valores têm:

IfNotPresent

a imagem será baixada apenas se não estiver presente localmente.

Always

toda vez que o kubelet iniciar um contêiner, ele consultará o registro de imagens de contêiner para resolver o nome para um digest. Se o kubelet tiver uma imagem de contêiner com exatamente esse digest em cache local, ele usará a imagem em cache; caso contrário, o kubelet fará o download da imagem com o digest resolvido e usará essa imagem para iniciar o contêiner.

Never

o kubelet não tenta buscar a imagem. Se a imagem já estiver presente localmente de alguma forma, o kubelet tentará iniciar o contêiner; caso contrário, a inicialização falhará. Veja imagens pré-baixadas para mais detalhes.

A semântica de cache do provedor de imagens subjacente torna mesmo imagePullPolicy: Always eficiente, desde que o registro esteja acessível de forma confiável. Seu agente de execução de contêiner pode perceber que as camadas da imagem já existem no nó, evitando que precisem ser baixadas novamente.

Para garantir que o Pod sempre use a mesma versão de uma imagem de contêiner, você pode especificar o digest da imagem; substitua <image-name>:<tag> por <image-name>@<digest> (por exemplo, image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2).

Ao usar tags de imagem, se o registro de imagens alterar o código que a tag representa, você pode acabar com uma mistura de Pods executando o código antigo e o novo. Um digest de imagem identifica de forma única uma versão específica da imagem, então o Kubernetes executa o mesmo código sempre que inicia um contêiner com aquele nome de imagem e digest especificado. Especificar uma imagem por digest fixa o código que será executado, de modo que uma alteração no registro não leve a essa mistura de versões.

Existem controladores de admissão de terceiros que mutam Pods (e templates de Pods) quando eles são criados, de forma que a carga de trabalho em execução seja definida com base em um digest de imagem em vez de uma tag. Isso pode ser útil se você quiser garantir que toda sua carga de trabalho esteja executando o mesmo código, independentemente das mudanças de tags no registro.

Política padrão de download de imagem

Quando você (ou um controlador) envia um novo Pod para o servidor de API, seu cluster define o campo imagePullPolicy quando certas condições são atendidas:

• se você omitir o campo imagePullPolicy e especificar o digest da imagem do contêiner, o imagePullPolicy será automaticamente definido como IfNotPresent;
• se você omitir o campo imagePullPolicy e a tag da imagem do contêiner for :latest, o imagePullPolicy será automaticamente definido como Always;
• se você omitir o campo imagePullPolicy e não especificar uma tag para a imagem do contêiner, o imagePullPolicy será automaticamente definido como Always;
• se você omitir o campo imagePullPolicy e especificar uma tag para a imagem do contêiner que não seja :latest, o imagePullPolicy será automaticamente definido como IfNotPresent.

Download obrigatório da imagem

Se você deseja forçar sempre o download da imagem, pode fazer uma das seguintes opções:

• Defina o imagePullPolicy do contêiner como Always.
• Omita o imagePullPolicy e use :latest como a tag da imagem a ser usada; o Kubernetes definirá a política como Always ao enviar o Pod.
• Omita o imagePullPolicy e a tag da imagem a ser usada; o Kubernetes definirá a política como Always ao enviar o Pod.
• Ative o controlador de admissão AlwaysPullImages.

ImagePullBackOff

Quando o kubelet começa a criar contêineres para um Pod usando um agente de execução de contêiner, é possível que o contêiner esteja no estado Waiting devido a ImagePullBackOff.

O status ImagePullBackOff significa que um contêiner não pôde ser iniciado porque o Kubernetes não conseguiu fazer o download da imagem do contêiner (por motivos como nome de imagem inválido ou tentativa de download de um registro privado sem imagePullSecret). A parte BackOff indica que o Kubernetes continuará tentando fazer o download da imagem, com um atraso incremental entre as tentativas.

O Kubernetes aumenta o intervalo entre cada tentativa até atingir um limite definido no código, que é de 300 segundos (5 minutos).

Download de imagem por classe de agente de execução

Se você habilitar o feature gate RuntimeClassInImageCriApi, o kubelet passará a referenciar imagens de contêiner por uma tupla (nome da imagem, manipulador de agente de execução) em vez de apenas pelo nome da imagem ou digest. Seu agente de execução do contêiner pode adaptar seu comportamento com base no manipulador de agente de execução selecionado. Fazer download de imagens com base na classe de agente de execução será útil para contêineres baseados em máquina virtual, como contêineres do tipo Windows Hyper-V.

Downloads de imagem em série e em paralelo

Por padrão, o kubelet realiza downloads de imagens de forma sequencial. Em outras palavras, o kubelet envia apenas uma solicitação de download de imagem por vez para o serviço de imagens. Outras solicitações de download precisam aguardar até que a solicitação em andamento seja concluída.

Os Nós tomam decisões de download de imagem de forma isolada. Mesmo quando você usa downloads de imagem em série, dois Nós diferentes podem puxar a mesma imagem em paralelo.

Se você quiser habilitar downloads de imagem em paralelo, pode definir o campo serializeImagePulls como false na configuração do kubelet. Com serializeImagePulls definido como false, as solicitações de download de imagem serão enviadas imediatamente para o serviço de imagens, permitindo que várias imagens sejam puxadas ao mesmo tempo.

Ao habilitar downloads de imagem em paralelo, certifique-se de que o serviço de imagens do seu agente de execução do contêiner pode lidar com esse tipo de operação.

O kubelet nunca realiza download de múltiplas imagens em paralelo para um único Pod. Por exemplo, se você tiver um Pod com um Init Container e um contêiner de aplicação, os downloads de imagem desses dois contêineres não serão paralelizados. No entanto, se você tiver dois Pods que usam imagens diferentes, o kubelet puxará as imagens em paralelo para os dois Pods diferentes, quando o download paralelo estiver habilitado.

Máximo de downloads de imagem em paralelo

Quando serializeImagePulls está definido como false, o kubelet, por padrão, não impõe limite ao número máximo de imagens sendo puxadas ao mesmo tempo. Se você quiser limitar a quantidade de downloads de imagem paralelos, pode definir o campo maxParallelImagePulls na configuração do kubelet. Com maxParallelImagePulls definido como n, apenas n imagens podem ser puxadas simultaneamente, e qualquer download de imagem além de n terá que aguardar até que pelo menos um download em andamento seja concluído.

Limitar o número de downloads de imagem paralelos ajuda a evitar que o processo de download consuma muita largura de banda de rede ou I/O de disco quando esta funcionalidade estiver habilitada.

Você pode definir maxParallelImagePulls para um número positivo maior ou igual a 1. Se você definir maxParallelImagePulls como maior ou igual a 2, também deverá definir serializeImagePulls como false. O kubelet não iniciará se as configurações de maxParallelImagePulls forem inválidas.

Multiarquitetura de imagens com índice de imagens

Além de fornecer o binário das imagens, um registro de contêiner também pode servir um índice de imagem do contêiner. Um índice de imagem pode apontar para múltiplos manifestos da imagem para versões específicas de arquitetura de um contêiner. A ideia é que você possa ter um nome para uma imagem (por exemplo: pause, exemple/meuconteiner, kube-apiserver) e permitir que diferentes sistemas busquem o binário da imagem correta para a arquitetura de máquina que estão usando.

O próprio Kubernetes normalmente nomeia as imagens de contêiner com o sufixo -$(ARCH). Para retrocompatibilidade, gere as imagens mais antigas com sufixos. A ideia é gerar a imagem pause que tem o manifesto para todas as arquiteturas e pause-amd64 que é retrocompatível com as configurações anteriores ou arquivos YAML que podem ter codificado as imagens com sufixos.

Usando um registro privado

Os registros privados podem exigir chaves para acessar as imagens deles. As credenciais podem ser fornecidas de várias maneiras:

• Configurando nós para autenticação em um registro privado
  • todos os pods podem ler qualquer registro privado configurado
  • requer configuração de nó pelo administrador do cluster
• Imagens pré-obtidas
  • todos os pods podem usar qualquer imagem armazenada em cache em um nó
  • requer acesso root a todos os nós para configurar
• Especificando ImagePullSecrets em um Pod
  • apenas pods que fornecem chaves próprias podem acessar o registro privado
• Extensões locais ou específicas do fornecedor
  • se estiver usando uma configuração de nó personalizado, você (ou seu provedor de nuvem) pode implementar seu mecanismo para autenticar o nó ao registro do contêiner.

Essas opções são explicadas com mais detalhes abaixo.

Configurando nós para autenticação em um registro privado

As instruções específicas para configurar as credenciais dependem do agente de execução de contêiner e do registro que você escolheu utilizar. Você deve consultar a documentação da sua solução para obter as informações mais precisas.

Para um exemplo de configuração de um registro de imagens de contêiner privado, veja a tarefa Realizar download de uma Imagem a partir de um Registro Privado. Esse exemplo utiliza um registro privado no Docker Hub.

Provedor de credenciais do kubelet para downloads de imagem autenticados

Você pode configurar o kubelet para invocar um binário de plugin a fim de buscar dinamicamente as credenciais de registro para uma imagem de contêiner. Essa é a maneira mais robusta e versátil de obter credenciais para registros privados, mas também exige uma configuração no nível do kubelet para ser habilitada.

Veja Configurar um provedor de credenciais de imagem no kubelet para mais detalhes.

Interpretação do config.json

A interpretação do config.json varia entre a implementação original do Docker e a interpretação feita pelo Kubernetes. No Docker, as chaves em auths podem especificar apenas URLs raiz, enquanto o Kubernetes permite URLs com glob e também caminhos com correspondência por prefixo. A única limitação é que os padrões glob (*) devem incluir o ponto (.) para cada subdomínio. A quantidade de subdomínios correspondentes deve ser igual à quantidade de padrões glob (*.), por exemplo:

• *.kubernetes.io não corresponderá a kubernetes.io, mas corresponderá a abc.kubernetes.io
• *.*.kubernetes.io não corresponderá a abc.kubernetes.io, mas corresponderá a abc.def.kubernetes.io
• prefix.*.io corresponderá a prefix.kubernetes.io
• *-good.kubernetes.io corresponderá a prefix-good.kubernetes.io

Isso significa que um config.json como este é válido:

{
    "auths": {
        "my-registry.io/images": { "auth": "…" },
        "*.my-registry.io/images": { "auth": "…" }
    }
}

As operações de pull de imagem agora passarão as credenciais para o agente de execução de contêiner via CRI para cada padrão válido. Por exemplo, os seguintes nomes de imagem de contêiner corresponderiam com sucesso:

• my-registry.io/images
• my-registry.io/images/my-image
• my-registry.io/images/another-image
• sub.my-registry.io/images/my-image

Mas não:

• a.sub.my-registry.io/images/my-image
• a.b.sub.my-registry.io/images/my-image

O kubelet realiza downloads de imagem de forma sequencial para cada credencial encontrada. Isso significa que múltiplas entradas no config.json para caminhos diferentes também são possíveis:

{
    "auths": {
        "my-registry.io/images": {
            "auth": "…"
        },
        "my-registry.io/images/subpath": {
            "auth": "…"
        }
    }
}

Se agora um contêiner especificar uma imagem my-registry.io/images/subpath/my-image para ser baixada, o kubelet tentará fazer o download utilizando ambas as fontes de autenticação, caso uma delas falhe.

Imagens pré-obtidas

Por padrão, o kubelet tenta realizar um "pull" para cada imagem do registro especificado. No entanto, se a propriedade imagePullPolicy do contêiner for definida como IfNotPresent ou Never, em seguida, uma imagem local é usada (preferencial ou exclusivamente, respectivamente).

Se você quiser usar imagens pré-obtidas como um substituto para a autenticação do registro, você deve garantir que todos os nós no cluster tenham as mesmas imagens pré-obtidas.

Isso pode ser usado para pré-carregar certas imagens com o intuíto de aumentar a velocidade ou como uma alternativa para autenticação em um registro privado.

Todos os pods terão permissão de leitura a quaisquer imagens pré-obtidas.

Especificando imagePullSecrets em um pod

O Kubernetes oferece suporte à especificação de chaves de registro de imagem de contêiner em um Pod. Todos os imagePullSecrets devem estar no mesmo namespace que o Pod. Os Secrets referenciados devem ser do tipo kubernetes.io/dockercfg ou kubernetes.io/dockerconfigjson.

Criando um segredo com Docker config

Você precisa saber o nome de usuário, a senha do registro, o endereço de e-mail do cliente para autenticação no registro, além do nome do host. Execute o seguinte comando, substituindo os valores em letras maiúsculas pelos apropriados:

kubectl create secret docker-registry <name> \
  --docker-server=DOCKER_REGISTRY_SERVER \
  --docker-username=DOCKER_USER \
  --docker-password=DOCKER_PASSWORD \
  --docker-email=DOCKER_EMAIL

Se você já tem um arquivo de credenciais do Docker, em vez de usar o comando acima, você pode importar o arquivo de credenciais como um Kubernetes Secrets. Criar um segredo com base nas credenciais Docker existentes explica como configurar isso.

Isso é particularmente útil se você estiver usando vários registros privados de contêineres, como kubectl create secret docker-registry cria um Segredo que só funciona com um único registro privado.

Referenciando um imagePullSecrets em um pod

Agora, você pode criar Pods que referenciam esse Secret adicionando uma seção imagePullSecrets na definição do Pod. Cada item no array imagePullSecrets pode referenciar apenas um Secret no mesmo namespace.

Por exemplo:

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey
EOF

cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

Isso precisa ser feito para cada pod que está usando um registro privado.

No entanto, a configuração deste campo pode ser automatizada definindo o imagePullSecrets em um recurso de ServiceAccount.

Verifique Adicionar ImagePullSecrets a uma conta de serviço para obter instruções detalhadas.

Você pode usar isso em conjunto com um .docker / config.json por nó. As credenciais serão mescladas.

Casos de uso

Existem várias soluções para configurar registros privados. Aqui estão alguns casos de uso comuns e soluções sugeridas.

1. Cluster executando apenas imagens não proprietárias (por exemplo, código aberto). Não há necessidade de ocultar imagens.
   • Use imagens públicas no Docker hub.
     • Nenhuma configuração necessária.
     • Alguns provedores de nuvem armazenam em cache ou espelham automaticamente imagens públicas, o que melhora a disponibilidade e reduz o tempo para extrair imagens.
2. Cluster executando algumas imagens proprietárias que devem ser ocultadas para quem está fora da empresa, mas visível para todos os usuários do cluster.
   • Use um registro Docker privado hospedado.
     • Pode ser hospedado no Docker Hub ou em outro lugar.
     • Configure manualmente .docker/config.json em cada nó conforme descrito acima.
   • Ou execute um registro privado interno atrás de seu firewall com permissão de leitura.
     • Nenhuma configuração do Kubernetes é necessária.
   • Use um serviço de registro de imagem de contêiner que controla o acesso à imagem
     • Funcionará melhor com o escalonamento automático do cluster do que com a configuração manual de nós.
   • Ou, em um cluster onde alterar a configuração do nó é inconveniente, use imagePullSecrets.
3. Cluster com imagens proprietárias, algumas das quais requerem controle de acesso mais rígido.
   • Certifique-se de que o controlador de admissão AlwaysPullImages está ativo. Caso contrário, todos os pods têm potencialmente acesso a todas as imagens.
   • Mova dados confidenciais para um recurso "secreto", em vez de empacotá-los em uma imagem.
4. Um cluster multilocatário em que cada locatário precisa de seu próprio registro privado.
   • Certifique-se de que o controlador de admissão AlwaysPullImages está ativo. Caso contrário, todos os Pods de todos os locatários terão potencialmente acesso a todas as imagens.
   • Execute um registro privado com autorização necessária.
   • Gere credenciais de registro para cada locatário, coloque em segredo e preencha o segredo para cada namespace de locatário.
   • O locatário adiciona esse segredo a imagePullSecrets de cada namespace.

Se precisar de acesso a vários registros, você pode criar um segredo para cada registro.

Provedor de credenciais legado embutido no kubelet

Em versões mais antigas do Kubernetes, o kubelet tinha uma integração direta com as credenciais de provedores de nuvem. Isso permitia buscar dinamicamente as credenciais para registros de imagens.

Havia três implementações embutidas do provedor de credenciais do kubelet: ACR (Azure Container Registry), ECR (Elastic Container Registry) e GCR (Google Container Registry).

Para mais informações sobre o mecanismo legado, consulte a documentação da versão do Kubernetes que você está utilizando. As versões do Kubernetes da v1.26 até a v1.35 não incluem mais esse mecanismo legado, portanto, você precisará:

• configurar um provedor de credenciais de imagem no kubelet em cada nó
• ou especificar credenciais de download de imagem usando imagePullSecrets e pelo menos um Secret

Próximos passos

• Leia a Especificação do Manifesto de Imagem OCI
• Saiba mais sobre coleta de lixo de imagens de contêiner.
• Saiba mais sobre realizar download de uma imagem a partir de um registro privado.

5.2 - Ambiente de Contêiner

Essa página descreve os recursos disponíveis para contêineres no ambiente de contêiner.

Ambiente de contêiner

O ambiente de contêiner do Kubernetes fornece recursos importantes para contêineres:

• Um sistema de arquivos, que é a combinação de uma imagem e um ou mais volumes.
• Informação sobre o contêiner propriamente.
• Informação sobre outros objetos no cluster.

Informação de contêiner

O hostname de um contêiner é o nome do Pod em que o contêiner está executando. Isso é disponibilizado através do comando hostname ou da função gethostname chamada na libc.

O nome do Pod e o Namespace são expostos como variáveis de ambiente através de um mecanismo chamado downward API.

Variáveis de ambiente definidas pelo usuário a partir da definição do Pod também são disponíveis para o contêiner, assim como qualquer variável de ambiente especificada estáticamente na imagem Docker.

Informação do cluster

Uma lista de todos os serviços que estão executando quando um contêiner foi criado é disponibilizada para o contêiner como variáveis de ambiente. Essas variáveis de ambiente são compatíveis com a funcionalidade docker link do Docker.

Para um serviço nomeado foo que mapeia para um contêiner nomeado bar, as seguintes variáveis são definidas:

FOO_SERVICE_HOST=<o host em que o serviço está executando>
FOO_SERVICE_PORT=<a porta em que o serviço está executando>

Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS, se possuírem DNS addon habilitado.

Próximos passos

• Aprenda mais sobre hooks de ciclo de vida do contêiner.
• Obtenha experiência prática anexando manipuladores a eventos de ciclo de vida do contêiner.

5.3 - Classes de execução

Essa página descreve o recurso RuntimeClass e a seleção do mecanismo do agente de execução.

RuntimeClass é uma funcionalidade para selecionar as configurações do agente de execução do contêiner. A configuração do agente de execução de contêineres é usada para executar os contêineres de um Pod.

Motivação

Você pode configurar um RuntimeClass diferente entre os diferentes Pods para prover um equilíbrio entre performance versus segurança. Por exemplo, se parte de sua carga de trabalho necessita de um alto nível de garantia de segurança da informação, você pode optar em executar esses Pods em um agente de execução que usa virtualização de hardware. Você então terá o benefício do isolamento extra de um agente de execução alternativo, ao custo de uma latência adicional.

Você pode ainda usar um RuntimeClass para executar diferentes Pods com o mesmo agente de execução de contêineres mas com diferentes configurações.

Configuração

1. Configure a implementação do CRI nos nós (depende do agente de execução)
2. Crie o recurso RuntimeClass correspondente.

1. Configure a implementação do CRI nos nós

As configurações disponíveis através do RuntimeClass sáo dependentes da implementação do Container Runtime Interface (Container runtime interface (CRI)). Veja a documentação correspondente abaixo para a sua implementação CRI para verificar como configurar.

As configurações possuem um nome handler correspondente, referenciado pelo RuntimeClass. Esse nome deve ser um valor DNS 1123 válido (letras, números e o carácter -).

2. Crie o recurso RuntimeClass correspondente

As etapas de configuração no passo 1 devem todas estar associadas a um nome para o campo handler que identifica a configuração. Para cada um, crie o objeto RuntimeClass correspondente.

O recurso RuntimeClass atualmente possui apenas 2 campos significativos: o nome do RuntimeClass (metadata.name) e o agente (handler). A definição do objeto se parece conforme a seguir:

apiVersion: node.k8s.io/v1  # RuntimeClass é definido no grupo de API node.k8s.io
kind: RuntimeClass
metadata:
  name: myclass  # O nome que o RuntimeClass será chamado como
  # RuntimeClass é um recurso global, e não possui namespace.
handler: myconfiguration  # Nome da configuração CRI correspondente

O nome de um objeto RuntimeClass deve ser um nome de subdomínio DNS válido.

Uso

Uma vez que as classes de execução estão configuradas no cluster, usar elas é relativamente simples. Especifique um runtimeClassName na especificação do Pod. Por exemplo:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

Isso irá instruir o kubelet a usar o RuntimeClass nomeado acima (myclass) para esse Pod. Se o nome do RuntimeClass não existir, ou o CRI não puder executar a solicitação, o Pod entrará na fase final Failed. Procure por um evento correspondente para uma mensagem de erro.

Se nenhum runtimeClassName for especificado, o RuntimeHandler padrão será utilizado, que é equivalente ao comportamento quando a funcionalidade de RuntimeClass está desativada.

Configuração do CRI

Para maiores detalhes de configuração dos agentes de execução CRI, veja instalação do CRI.

dockershim

O CRI dockershim embutido no Kubernetes não suporta outros agentes de execução.

containerd

Agentes de execução são configurados através da configuração do containerd em /etc/containerd/config.toml. Agentes válidos são configurados sob a seção de runtimes:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

Veja a documentação de configuração do containerd para maiores detalhes: https://github.com/containerd/containerd/blob/main/docs/cri/config.md

CRI-O

Agentes de execução são configurados através da configuração do CRI-O em /etc/crio/crio.conf. Agentes válidos são configurados na seção crio.runtime table:

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

Veja a documentação de configuração do CRI-O para maiores detalhes.

Associação

Ao especificar o campo scheduling para um RuntimeClass, você pode colocar limites e garantir que os Pods executando dentro de uma RuntimeClass sejam associados a nós que suportem eles. Se o scheduling não estiver configurado, assume-se que esse RuntimeClass é suportado por todos os nós.

Para garantir que os Pods sejam executados em um nó que suporte um RuntimeClass específico, aquele conjunto de nós deve possuir uma marca/label padrão que é selecionado pelo campo runtimeclass.scheduling.nodeSelector. O nodeSelector do RuntimeClass é combinado com o nodeSelector do Pod em tempo de admissão, obtendo a intersecção do conjunto de nós selecionado por cada. Se existir um conflito, o pod será rejeitado.

Se os nós suportados possuírem marcação de restrição para prevenir outros Pods com uma classe de execução diferente de executar no nó, você pode adicionar o campo tolerations ao objeto RuntimeClass. Assim como com o nodeSelector, o tolerations é combinado com o campo tolerations do Pod em tempo de admissão, efetivamente pegando a intersecção do conjunto de nós aplicáveis para cada.

Para saber mais sobre a configuração de seleção de nós e tolerâncias, veja Associando Pods a Nós.

Sobrecarga de Pods

Você pode especificar os recursos extra que estão associados à execução de um Pod. Declarar esses recursos extra permite ao cluster (incluindo o agendador/scheduler de pods) contabilizar por esses recursos quando estiver decidindo sobre Pods e recursos. Para usar a contabilização desses recursos extras, você deve estar com o feature gate PodOverhead habilitado (ele já está habilitado por padrão).

Os recursos extras utilizados são especificados no objeto RuntimeClass através do campo overhead. Ao usar esses campos, você especifica o uso extra de recursos necessários para executar Pods utilizando-se desse Runtimeclass e assim contabilizar esses recursos para o Kubernetes.

Próximos passos

• RuntimeClass Design
• RuntimeClass Scheduling Design
• Leia mais sobre Sobrecarga de Pods
• PodOverhead Feature Design

5.4 - Hooks de Ciclo de Vida do Contêiner

Essa página descreve como os contêineres gerenciados pelo kubelet podem usar a estrutura de hook de ciclo de vida do contêiner para executar código acionado por eventos durante seu ciclo de vida de gerenciamento.

Visão Geral

Análogo a muitas estruturas de linguagem de programação que tem hooks de ciclo de vida de componentes, como angular, o Kubernetes fornece aos contêineres hooks de ciclo de vida. Os hooks permitem que os contêineres estejam cientes dos eventos em seu ciclo de vida de gerenciamento e executem código implementado em um manipulador quando o hook de ciclo de vida correspondente é executado.

Hooks do contêiner

Existem dois hooks que são expostos para os contêiners:

PostStart

Este hook é executado imediatamente após um contêiner ser criado. Entretanto, não há garantia que o hook será executado antes do ENTRYPOINT do contêiner. Nenhum parâmetro é passado para o manipulador.

PreStop

Esse hook é chamado imediatamente antes de um contêiner ser encerrado devido a uma solicitação de API ou um gerenciamento de evento como liveness/startup probe failure, preemption, resource contention e outros. Uma chamada ao hook PreStop falha se o contêiner já está em um estado finalizado ou concluído e o hook deve ser concluído antes que o sinal TERM seja enviado para parar o contêiner. A contagem regressiva do período de tolerância de término do Pod começa antes que o hook PreStop seja executado, portanto, independentemente do resultado do manipulador, o contêiner será encerrado dentro do período de tolerância de encerramento do Pod. Nenhum parâmetro é passado para o manipulador.

Uma descrição mais detalhada do comportamento de término pode ser encontrada em Término de Pods.

Implementações de manipulador de hook

Os contêineres podem acessar um hook implementando e registrando um manipulador para esse hook. Existem dois tipos de manipuladores de hooks que podem ser implementados para contêineres:

• Exec - Executa um comando específico, como pre-stop.sh, dentro dos cgroups e Namespaces do contêiner.
• HTTP - Executa uma requisição HTTP em um endpoint específico do contêiner.

Execução do manipulador de hook

Quando um hook de gerenciamento de ciclo de vida do contêiner é chamado, o sistema de gerenciamento do Kubernetes executa o manipulador de acordo com a ação do hook, httpGet e tcpSocket são executados pelo processo kubelet e exec é executado pelo contêiner.

As chamadas do manipulador do hook são síncronas no contexto do Pod que contém o contêiner. Isso significa que para um hook PostStart, o ENTRYPOINT do contêiner e o hook disparam de forma assíncrona. No entanto, se o hook demorar muito para ser executado ou travar, o contêiner não consegue atingir o estado running.

Os hooks PreStop não são executados de forma assíncrona a partir do sinal para parar o contêiner, o hook precisa finalizar a sua execução antes que o sinal TERM possa ser enviado. Se um hook PreStop travar durante a execução, a fase do Pod será Terminating e permanecerá até que o Pod seja morto após seu terminationGracePeriodSeconds expirar. Esse período de tolerância se aplica ao tempo total necessário para o hook PreStopexecutar e para o contêiner parar normalmente. Se por exemplo, o terminationGracePeriodSeconds é 60, e o hook leva 55 segundos para ser concluído, e o contêiner leva 10 segundos para parar normalmente após receber o sinal, então o contêiner será morto antes que possa parar normalmente, uma vez que o terminationGracePeriodSeconds é menor que o tempo total (55 + 10) que é necessário para que essas duas coisas aconteçam.

Se um hook PostStart ou PreStop falhar, ele mata o contêiner.

Os usuários devem tornar seus hooks o mais leve possíveis. Há casos, no entanto, em que comandos de longa duração fazem sentido, como ao salvar o estado antes de parar um contêiner.

Garantias de entrega de hooks

A entrega do hook é destinada a acontecer pelo menos uma vez, o que quer dizer que um hook pode ser chamado várias vezes para qualquer evento, como para PostStart ou PreStop. Depende da implementação do hook lidar com isso corretamente.

Geralmente, apenas entregas únicas são feitas. Se, por exemplo, um receptor de hook HTTP estiver inativo e não puder receber tráfego, não há tentativa de reenviar. Em alguns casos raros, no entanto, pode ocorrer uma entrega dupla. Por exemplo, se um kubelet reiniciar no meio do envio de um hook, o hook pode ser reenviado depois que o kubelet voltar a funcionar.

Depurando manipuladores de hooks

Os logs para um manipulador de hook não são expostos em eventos de Pod. Se um manipulador falhar por algum motivo, ele transmitirá um evento. Para PostStart é o evento FailedPostStartHook e para PreStop é o evento FailedPreStopHook. Você pode ver esses eventos executando kubectl describe pod <nome_do_pod>. Aqui está um exemplo de saída de eventos da execução deste comando:

Events:
  FirstSeen  LastSeen  Count  From                                                   SubObjectPath          Type      Reason               Message
  ---------  --------  -----  ----                                                   -------------          --------  ------               -------
  1m         1m        1      {default-scheduler }                                                          Normal    Scheduled            Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulling              pulling image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Created              Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulled               Successfully pulled image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Started              Started container with docker id 5c6a256a2567
  38s        38s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
  37s        37s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
  38s        37s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                         Warning   FailedSync           Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
  1m         22s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Warning   FailedPostStartHook

Próximos passos

• Saiba mais sobre o Ambiente de contêiner.
• Obtenha experiência prática anexando manipuladores a eventos de ciclo de vida do contêiner.

6 - Serviços, balanceamento de carga e conectividade

O modelo de rede do Kubernetes

O modelo de rede do Kubernetes é construído a partir de várias partes:

• Cada pod em um cluster recebe seu próprio endereço IP exclusivo em todo o cluster.

  • Um pod possui seu próprio namespace de rede privado que é compartilhado por todos os contêineres dentro do pod. Processos em execução em contêineres diferentes no mesmo pod podem se comunicar entre si através do localhost.

• A rede de pods (também chamada de rede do cluster) gerencia a comunicação entre pods. Ela garante que (exceto por segmentação de rede intencional):

  • Todos os pods podem se comunicar com todos os outros pods, estejam eles no mesmo nó ou em nós diferentes. Os pods podem se comunicar entre si diretamente, sem o uso de proxies ou tradução de endereços (NAT).

    No Windows, esta regra não se aplica a pods de rede do host.

  • Agentes em um nó (como daemons do sistema ou kubelet) podem se comunicar com todos os pods naquele nó.

• A API de Service permite que você forneça um endereço IP ou hostname estável (de longa duração) para um serviço implementado por um ou mais pods de backend, onde os pods individuais que compõem o serviço podem mudar ao longo do tempo.

  • O Kubernetes gerencia automaticamente objetos EndpointSlice para fornecer informações sobre os pods atualmente oferecendo suporte a um Service.

  • Uma implementação de proxy de serviço monitora o conjunto de objetos Service e EndpointSlice, e programa a camada de dados para rotear o tráfego de serviço para seus backends, usando APIs do sistema operacional ou provedor de nuvem para interceptar ou reescrever pacotes.

• A API de Gateway (ou sua predecessora, Ingress) permite que você torne Services acessíveis a clientes que estão fora do cluster.

  • Um mecanismo mais simples, mas menos configurável, para entrada no cluster está disponível através do type: LoadBalancer da API Service, ao usar um Provedor de Nuvem compatível.

• NetworkPolicy é uma API embutida do Kubernetes que permite controlar o tráfego entre pods, ou entre pods e o mundo externo.

Em sistemas de contêineres mais antigos, não havia conectividade automática entre contêineres em hosts diferentes, e por isso era frequentemente necessário criar explicitamente links entre contêineres, ou mapear portas de contêineres para portas do host para torná-los acessíveis por contêineres em outros hosts. Isso não é necessário no Kubernetes; o modelo do Kubernetes é que os pods podem ser tratados de forma muito semelhante a VMs ou hosts físicos das perspectivas de alocação de portas, nomenclatura, descoberta de serviços, balanceamento de carga, configuração de aplicações e migração.

Apenas algumas partes deste modelo são implementadas pelo próprio Kubernetes. Para as outras partes, o Kubernetes define as APIs, mas a funcionalidade correspondente é fornecida por componentes externos, alguns dos quais são opcionais:

• A configuração do namespace de rede do pod é gerenciada por software de nível de sistema que implementa a Interface de Agente de Execução de Contêiner.

• A própria rede de pods é gerenciada por uma implementação de rede de pods. No Linux, a maioria dos agentes de execução de contêineres usa a Interface de Rede de Contêineres (CNI) para interagir com a implementação de rede de pods, então essas implementações são frequentemente chamadas de plugins CNI.

• O Kubernetes fornece uma implementação padrão de proxy de serviço, chamada kube-proxy, mas algumas implementações de rede de pods usam seu próprio proxy de serviço que é mais fortemente integrado com o restante da implementação.

• NetworkPolicy geralmente também é implementado pela implementação de rede de pods. (Algumas implementações de rede de pods mais simples não implementam NetworkPolicy, ou um administrador pode optar por configurar a rede de pods sem suporte a NetworkPolicy. Nestes casos, a API ainda estará presente, mas não terá efeito.)

• Existem muitas implementações de Gateway API, algumas das quais são específicas para ambientes de nuvem particulares, algumas mais focadas em ambientes "bare metal", e outras mais genéricas.

Próximos passos

O tutorial Conectando Aplicações com Services permite que você aprenda sobre Services e rede do Kubernetes com um exemplo prático.

Conectividade do Cluster explica como configurar a rede para o seu cluster, e também fornece uma visão geral das tecnologias envolvidas.

6.1 - Service

No Kubernetes, um Service é uma forma abstrata de expor uma aplicação que está executando em um conjunto de Pods como um serviço de rede.

Um objetivo fundamental dos Services no Kubernetes é que você não precise modificar sua aplicação existente para usar um mecanismo de descoberta de serviços desconhecido. Você pode executar código em Pods, seja um código projetado para um mundo nativo em nuvem, ou uma aplicação mais antiga que você containerizou. Você usa um Service para tornar esse conjunto de Pods disponível na rede para que os clientes possam interagir com ele.

Se você usa um Deployment para executar sua aplicação, esse Deployment pode criar e destruir Pods dinamicamente. De um momento para o outro, você não sabe quantos desses Pods estão funcionando e íntegros; você pode nem mesmo saber como esses Pods íntegros são nomeados. Os Pods do Kubernetes são criados e destruídos para corresponder ao estado desejado do seu cluster. Pods são recursos efêmeros (você não deve esperar que um Pod individual seja confiável e durável).

Cada Pod obtém seu próprio endereço IP (o Kubernetes espera que os plugins de rede garantam isso). Para um determinado Deployment no seu cluster, o conjunto de Pods em execução em um momento no tempo pode ser diferente do conjunto de Pods executando essa aplicação um momento depois.

Isso leva a um problema: se algum conjunto de Pods (chame-os de "backends") fornece funcionalidade para outros Pods (chame-os de "frontends") dentro do seu cluster, como os frontends descobrem e mantêm o controle de qual endereço IP conectar, para que o frontend possa usar a parte backend da carga de trabalho?

Entram os Services.

Services no Kubernetes

A API Service, parte do Kubernetes, é uma abstração para ajudá-lo a expor grupos de Pods em uma rede. Cada objeto Service define um conjunto lógico de endpoints (geralmente esses endpoints são Pods) junto com uma política sobre como tornar esses pods acessíveis.

Por exemplo, considere um backend de processamento de imagens sem estado que está em execução com 3 réplicas. Essas réplicas são fungíveis—os frontends não se importam com qual backend eles usam. Embora os Pods reais que compõem o conjunto de backend possam mudar, os clientes frontend não devem precisar estar cientes disso, nem devem precisar manter o controle do conjunto de backends por conta própria.

A abstração Service permite esse desacoplamento.

O conjunto de Pods direcionado por um Service geralmente é determinado por um seletor que você define. Para aprender sobre outras maneiras de definir endpoints de Service, consulte Services sem seletores.

Se sua carga de trabalho fala HTTP, você pode optar por usar um Ingress para controlar como o tráfego web alcança essa carga de trabalho. Ingress não é um tipo de Service, mas atua como o ponto de entrada para o seu cluster. Um Ingress permite que você consolide suas regras de roteamento em um único recurso, para que você possa expor múltiplos componentes da sua carga de trabalho, executando separadamente no seu cluster, atrás de um único ponto de entrada.

O Gateway API para Kubernetes fornece capacidades extras além de Ingress e Service. Você pode adicionar Gateway ao seu cluster - é uma família de APIs de extensão, implementadas usando CustomResourceDefinitions - e então usá-las para configurar o acesso a serviços de rede que estão em execução no seu cluster.

Descoberta de serviços nativos em nuvem

Se você puder usar as APIs do Kubernetes para descoberta de serviços na sua aplicação, você pode consultar o servidor de API para EndpointSlices correspondentes. O Kubernetes atualiza os EndpointSlices para um Service sempre que o conjunto de Pods em um Service muda.

Para aplicações não nativas, o Kubernetes oferece maneiras de colocar uma porta de rede ou balanceador de carga entre sua aplicação e os Pods de backend.

De qualquer forma, sua carga de trabalho pode usar esses mecanismos de descoberta de Services para encontrar o destino ao qual deseja se conectar.

Definindo um Service

Um Service é um objeto (da mesma forma que um Pod ou um ConfigMap é um objeto). Você pode criar, visualizar ou modificar definições de Service usando a API do Kubernetes. Normalmente você usa uma ferramenta como kubectl para fazer essas chamadas para a API.

Por exemplo, suponha que você tenha um conjunto de Pods que escutam na porta TCP 9376 e são rotulados como app.kubernetes.io/name=MyApp. Você pode definir um Service para publicar esse ponto de entrada TCP:

service/simple-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Aplicar esse manifesto cria um novo Service chamado "my-service" com o tipo de Service ClusterIP padrão. O Service direciona para a porta TCP 9376 em qualquer Pod com o rótulo app.kubernetes.io/name: MyApp.

O Kubernetes atribui a este Service um endereço IP (o IP do cluster), que é usado pelo mecanismo de endereço IP virtual. Para mais detalhes sobre esse mecanismo, leia IPs Virtuais e Proxies de Service.

O controlador para esse Service verifica continuamente por Pods que correspondam ao seu seletor, e então faz quaisquer atualizações necessárias ao conjunto de EndpointSlices para o Service.

O nome de um objeto Service deve ser um nome de rótulo RFC 1035 válido.

Requisitos de nomenclatura relaxados para objetos Service

O feature gate RelaxedServiceNameValidation permite que nomes de objetos Service comecem com um dígito. Quando este feature gate está habilitado, os nomes de objetos Service devem ser nomes de rótulo RFC 1123 válidos.

Definições de porta

Definições de porta em Pods têm nomes, e você pode referenciar esses nomes no atributo targetPort de um Service. Por exemplo, podemos vincular a targetPort do Service à porta do Pod da seguinte maneira:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app.kubernetes.io/name: proxy
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
      - containerPort: 80
        name: http-web-svc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app.kubernetes.io/name: proxy
  ports:
  - name: name-of-service-port
    protocol: TCP
    port: 80
    targetPort: http-web-svc

Isso funciona mesmo se houver uma mistura de Pods no Service usando um único nome configurado, com o mesmo protocolo de rede disponível através de diferentes números de porta. Isso oferece muita flexibilidade para implantar e evoluir seus Services. Por exemplo, você pode alterar os números de porta que os Pods expõem na próxima versão do seu software de backend, sem quebrar os clientes.

O protocolo padrão para Services é TCP; você também pode usar qualquer outro protocolo suportado.

Como muitos Services precisam expor mais de uma porta, o Kubernetes suporta múltiplas definições de porta para um único Service. Cada definição de porta pode ter o mesmo protocol, ou um diferente.

Services sem seletores

Services mais comumente abstraem o acesso a Pods do Kubernetes graças ao seletor, mas quando usados com um conjunto correspondente de objetos EndpointSlices e sem um seletor, o Service pode abstrair outros tipos de backends, incluindo aqueles que são executados fora do cluster.

Por exemplo:

• Você quer ter um cluster de banco de dados externo em produção, mas no seu ambiente de teste você usa seus próprios bancos de dados.
• Você quer apontar seu Service para um Service em um Namespace diferente ou em outro cluster.
• Você está migrando uma carga de trabalho para o Kubernetes. Ao avaliar a abordagem, você executa apenas uma parte dos seus backends no Kubernetes.

Em qualquer um desses cenários, você pode definir um Service sem especificar um seletor para corresponder aos Pods. Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376

Como este Service não tem seletor, os objetos EndpointSlice correspondentes não são criados automaticamente. Você pode mapear o Service para o endereço de rede e porta onde ele está sendo executado, adicionando um objeto EndpointSlice manualmente. Por exemplo:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
  name: my-service-1 # por convenção, use o nome do Service
                     # como um prefixo para o nome do EndpointSlice
  labels:
    # Você deve definir o rótulo "kubernetes.io/service-name".
    # Defina seu valor para corresponder ao nome do Service
    kubernetes.io/service-name: my-service
addressType: IPv4
ports:
  - name: http # deve corresponder ao nome da porta do service definida acima
    appProtocol: http
    protocol: TCP
    port: 9376
endpoints:
  - addresses:
      - "10.4.5.6"
  - addresses:
      - "10.1.2.3"

EndpointSlices personalizados

Quando você cria um objeto EndpointSlice para um Service, você pode usar qualquer nome para o EndpointSlice. Cada EndpointSlice em um namespace deve ter um nome único. Você vincula um EndpointSlice a um Service definindo o rótulo kubernetes.io/service-name nesse EndpointSlice.

Para um EndpointSlice que você criar por conta própria, ou no seu próprio código, você também deve escolher um valor para usar no rótulo endpointslice.kubernetes.io/managed-by. Se você criar seu próprio código de controlador para gerenciar EndpointSlices, considere usar um valor similar a "my-domain.example/name-of-controller". Se você estiver usando uma ferramenta de terceiros, use o nome da ferramenta em letras minúsculas e altere espaços e outras pontuações para traços (-). Se as pessoas estiverem usando diretamente uma ferramenta como kubectl para gerenciar EndpointSlices, use um nome que descreva esse gerenciamento manual, como "staff" ou "cluster-admins". Você deve evitar usar o valor reservado "controller", que identifica EndpointSlices gerenciados pela própria camada de gerenciamento do Kubernetes.

Acessando um Service sem seletor

Acessar um Service sem seletor funciona da mesma forma que se tivesse um seletor. No exemplo de um Service sem seletor, o tráfego é roteado para um dos dois endpoints definidos no manifesto EndpointSlice: uma conexão TCP para 10.1.2.3 ou 10.4.5.6, na porta 9376.

Um Service ExternalName é um caso especial de Service que não possui seletores e usa nomes DNS em vez disso. Para mais informações, consulte a seção ExternalName.

EndpointSlices

EndpointSlices são objetos que representam um subconjunto (uma fatia) dos endpoints de rede de suporte para um Service.

Seu cluster Kubernetes rastreia quantos endpoints cada EndpointSlice representa. Se houver tantos endpoints para um Service que um limite seja atingido, então o Kubernetes adiciona outro EndpointSlice vazio e armazena novas informações de endpoint lá. Por padrão, o Kubernetes cria um novo EndpointSlice assim que os EndpointSlices existentes contêm pelo menos 100 endpoints. O Kubernetes não cria o novo EndpointSlice até que um endpoint extra precise ser adicionado.

Consulte EndpointSlices para mais informações sobre esta API.

Endpoints (descontinuado)

A API EndpointSlice é a evolução da antiga API Endpoints. A API Endpoints descontinuada tem vários problemas em relação ao EndpointSlice:

• Ela não suporta clusters dual-stack.
• Ela não contém informações necessárias para suportar funcionalidades mais recentes, como trafficDistribution.
• Ela truncará a lista de endpoints se for muito longa para caber em um único objeto.

Devido a isso, é recomendado que todos os clientes usem a API EndpointSlice em vez de Endpoints.

Endpoints com capacidade excedida

O Kubernetes limita o número de endpoints que podem caber em um único objeto Endpoints. Quando há mais de 1000 endpoints de suporte para um Service, o Kubernetes trunca os dados no objeto Endpoints. Como um Service pode ser vinculado a mais de um EndpointSlice, o limite de 1000 endpoints de suporte afeta apenas a API Endpoints legada.

Nesse caso, o Kubernetes seleciona no máximo 1000 endpoints de backend possíveis para armazenar no objeto Endpoints, e define uma anotação no Endpoints: endpoints.kubernetes.io/over-capacity: truncated. A camada de gerenciamento também remove essa anotação se o número de Pods de backend cair abaixo de 1000.

O tráfego ainda é enviado para os backends, mas qualquer mecanismo de balanceamento de carga que dependa da API Endpoints legada envia tráfego apenas para no máximo 1000 dos endpoints de suporte disponíveis.

O mesmo limite da API significa que você não pode atualizar manualmente um Endpoints para ter mais de 1000 endpoints.

Protocolo de aplicação

O campo appProtocol fornece uma maneira de especificar um protocolo de aplicação para cada porta do Service. Isso é usado como uma dica para implementações oferecerem comportamento mais rico para protocolos que elas entendem. O valor deste campo é espelhado pelos objetos Endpoints e EndpointSlice correspondentes.

Este campo segue a sintaxe de rótulo padrão do Kubernetes. Valores válidos são um dos seguintes:

• Nomes de serviço padrão IANA.

• Nomes prefixados definidos pela implementação, como mycompany.com/my-custom-protocol.

• Nomes prefixados definidos pelo Kubernetes:

Services multi-porta

Para alguns Services, você precisa expor mais de uma porta. O Kubernetes permite que você configure múltiplas definições de porta em um objeto Service. Ao usar múltiplas portas para um Service, você deve dar nomes a todas as suas portas para que estas sejam inequívocas. Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377

Tipo de Service

Para algumas partes da sua aplicação (por exemplo, frontends) você pode querer expor um Service em um endereço IP externo, acessível de fora do seu cluster.

Os tipos de Service do Kubernetes permitem que você especifique que tipo de Service você deseja.

Os valores de type disponíveis e seus comportamentos são:

ClusterIP

Expõe o Service em um IP interno do cluster. Escolher este valor torna o Service acessível apenas de dentro do cluster. Este é o padrão usado se você não especificar explicitamente um type para um Service. Você pode expor o Service para a internet pública usando um Ingress ou um Gateway.

NodePort

Expõe o Service no IP de cada Node em uma porta estática (a NodePort). Para disponibilizar a porta do nó, o Kubernetes configura um endereço IP do cluster, o mesmo que se você tivesse solicitado um Service do type: ClusterIP.

LoadBalancer

Expõe o Service externamente usando um balanceador de carga externo. O Kubernetes não oferece diretamente um componente de balanceamento de carga; você deve fornecer um, ou pode integrar seu cluster Kubernetes com um provedor de nuvem.

ExternalName

Mapeia o Service para o conteúdo do campo externalName (por exemplo, para o nome de host api.foo.bar.example). O mapeamento configura o servidor DNS do seu cluster para retornar um registro CNAME com esse valor de nome de host externo. Nenhum tipo de proxy é configurado.

O campo type na API Service é projetado como funcionalidade aninhada - cada nível adiciona ao anterior. No entanto, há uma exceção a este design aninhado. Você pode definir um Service LoadBalancer desabilitando a alocação de NodePort do balanceador de carga.

type: ClusterIP

Este tipo de Service padrão atribui um endereço IP de um pool de endereços IP que seu cluster reservou para esse propósito.

Vários dos outros tipos de Service são construídos sobre o tipo ClusterIP como fundação.

Se você definir um Service que tenha o .spec.clusterIP definido como "None", então o Kubernetes não atribui um endereço IP. Consulte headless Services para mais informações.

Escolhendo seu próprio endereço IP

Você pode especificar seu próprio endereço IP do cluster como parte de uma requisição de criação de Service. Para fazer isso, defina o campo .spec.clusterIP. Por exemplo, se você já tem uma entrada DNS existente que deseja reutilizar, ou sistemas legados que estão configurados para um endereço IP específico e difíceis de reconfigurar.

O endereço IP que você escolher deve ser um endereço IPv4 ou IPv6 válido dentro do intervalo CIDR service-cluster-ip-range que está configurado para o servidor de API. Se você tentar criar um Service com um valor de clusterIP inválido, o servidor de API retornará um código de status HTTP 422 para indicar que há um problema.

Leia evitando conflitos para aprender como o Kubernetes ajuda a reduzir o risco e o impacto de dois Services diferentes tentando usar o mesmo endereço IP.

type: NodePort

Se você definir o campo type como NodePort, a camada de gerenciamento do Kubernetes aloca uma porta de um intervalo especificado pela flag --service-node-port-range (padrão: 30000-32767). Cada nó faz proxy dessa porta (o mesmo número de porta em cada Node) para o seu Service. Seu Service reporta a porta alocada no campo .spec.ports[*].nodePort.

Usar um NodePort lhe dá a liberdade de configurar sua própria solução de balanceamento de carga, configurar ambientes que não são totalmente suportados pelo Kubernetes, ou até mesmo expor diretamente os endereços IP de um ou mais nós.

Para um Service do tipo node port, o Kubernetes aloca adicionalmente uma porta (TCP, UDP ou SCTP para corresponder ao protocolo do Service). Cada nó no cluster se configura para escutar nessa porta atribuída e encaminhar o tráfego para um dos endpoints prontos associados a esse Service. Você poderá contatar o Service type: NodePort de fora do cluster, conectando-se a qualquer nó usando o protocolo apropriado (por exemplo: TCP), e a porta apropriada (conforme atribuída a esse Service).

Escolhendo sua própria porta

Se você deseja um número de porta específico, pode especificar um valor no campo nodePort. A camada de gerenciamento alocará essa porta para você ou reportará que a transação da API falhou. Isso significa que você precisa cuidar de possíveis conflitos de porta por conta própria. Você também precisa usar um número de porta válido, que esteja dentro do intervalo configurado para uso de NodePort.

Aqui está um exemplo de manifesto para um Service do type: NodePort que especifica um valor NodePort (30007, neste exemplo):

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - port: 80
      # Por padrão e por conveniência, a `targetPort` é definida com
      # o mesmo valor do campo `port`.
      targetPort: 80
      # Campo opcional
      # Por padrão e por conveniência, a camada de gerenciamento do Kubernetes
      # alocará uma porta de um intervalo (padrão: 30000-32767)
      nodePort: 30007

Reserve intervalos de Nodeport para evitar conflitos

A política para atribuir portas a services NodePort se aplica tanto aos cenários de atribuição automática quanto de atribuição manual. Quando um usuário deseja criar um service NodePort que usa uma porta específica, a porta de destino pode entrar em conflito com outra porta que já foi atribuída.

Para evitar este problema, o intervalo de portas para services NodePort é dividido em duas faixas. A atribuição dinâmica de portas usa a faixa superior por padrão, e pode usar a faixa inferior uma vez que a faixa superior tenha sido esgotada. Os usuários podem então alocar da faixa inferior com menor risco de conflito de porta.

Configuração de endereço IP personalizado para Services type: NodePort

Você pode configurar nós no seu cluster para usar um endereço IP específico para servir services de node port. Você pode querer fazer isso se cada nó estiver conectado a múltiplas redes (por exemplo: uma rede para tráfego de aplicação, e outra rede para tráfego entre nós e a camada de gerenciamento).

Se você deseja especificar endereço(s) IP particular(es) para fazer proxy da porta, você pode definir a flag --nodeport-addresses para o kube-proxy ou o campo equivalente nodePortAddresses do arquivo de configuração do kube-proxy para bloco(s) de IP particular(es).

Esta flag recebe uma lista delimitada por vírgulas de blocos de IP (por exemplo, 10.0.0.0/8, 192.0.2.0/25) para especificar intervalos de endereços IP que o kube-proxy deve considerar como locais para este nó.

Por exemplo, se você iniciar o kube-proxy com a flag --nodeport-addresses=127.0.0.0/8, o kube-proxy seleciona apenas a interface de loopback para Services NodePort. O padrão para --nodeport-addresses é uma lista vazia. Isso significa que o kube-proxy deve considerar todas as interfaces de rede disponíveis para NodePort. (Isso também é compatível com versões anteriores do Kubernetes.)

type: LoadBalancer

Em provedores de nuvem que suportam balanceadores de carga externos, definir o campo type como LoadBalancer provisiona um balanceador de carga para o seu Service. A criação real do balanceador de carga acontece de forma assíncrona, e informações sobre o balanceador provisionado são publicadas no campo .status.loadBalancer do Service. Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

O tráfego do balanceador de carga externo é direcionado aos Pods de backend. O provedor de nuvem decide como é feito o balanceamento de carga.

Para implementar um Service do type: LoadBalancer, o Kubernetes normalmente começa fazendo as alterações que são equivalentes a você solicitar um Service com type: NodePort. O componente cloud-controller-manager então configura o balanceador de carga externo para encaminhar o tráfego para essa porta de nó atribuída.

Você pode configurar um Service com balanceamento de carga para omitir a atribuição de uma porta de nó, desde que a implementação do provedor de nuvem suporte isso.

Alguns provedores de nuvem permitem que você especifique o loadBalancerIP. Nesses casos, o balanceador de carga é criado com o loadBalancerIP especificado pelo usuário. Se o campo loadBalancerIP não for especificado, o balanceador de carga é configurado com um endereço IP efêmero. Se você especificar um loadBalancerIP mas seu provedor de nuvem não suportar a funcionalidade, o campo loadbalancerIP que você definiu é ignorado.

Impacto da operacionalidade do nó no tráfego do balanceador de carga

As verificações de integridade do balanceador de carga são críticas para aplicações modernas. Elas são usadas para determinar para qual servidor (máquina virtual ou endereço IP) o balanceador de carga deve despachar o tráfego. As APIs do Kubernetes não definem como as verificações de integridade devem ser implementadas para balanceadores de carga gerenciados pelo Kubernetes, em vez disso, são os provedores de nuvem (e as pessoas implementando código de integração) que decidem sobre o comportamento. As verificações de integridade do balanceador de carga são extensivamente usadas no contexto de suportar o campo externalTrafficPolicy para Services.

Balanceadores de carga com tipos de protocolo mistos

Por padrão, para Services do tipo LoadBalancer, quando há mais de uma porta definida, todas as portas devem ter o mesmo protocolo, e o protocolo deve ser um que seja suportado pelo provedor de nuvem.

O feature gate MixedProtocolLBService (habilitado por padrão para o kube-apiserver a partir da v1.24) permite o uso de protocolos diferentes para Services do tipo LoadBalancer, quando há mais de uma porta definida.

Desabilitando a alocação de NodePort do balanceador de carga

Você pode opcionalmente desabilitar a alocação de node port para um Service do type: LoadBalancer, definindo o campo spec.allocateLoadBalancerNodePorts como false. Isso deve ser usado apenas para implementações de balanceador de carga que roteiam tráfego diretamente para Pods em vez de usar node ports. Por padrão, spec.allocateLoadBalancerNodePorts é true e Services do tipo LoadBalancer continuarão a alocar node ports. Se spec.allocateLoadBalancerNodePorts for definido como false em um Service existente com node ports alocados, esses node ports não serão desalocados automaticamente. Você deve remover explicitamente a entrada nodePorts em cada porta do Service para desalocar esses node ports.

Especificando a classe de implementação do balanceador de carga

Para um Service com type definido como LoadBalancer, o campo .spec.loadBalancerClass permite que você use uma implementação de balanceador de carga diferente do padrão do provedor de nuvem.

Por padrão, .spec.loadBalancerClass não está definido e um Service do tipo LoadBalancer usa a implementação de balanceador de carga padrão do provedor de nuvem se o cluster estiver configurado com um provedor de nuvem usando a flag de componente --cloud-provider.

Se você especificar .spec.loadBalancerClass, presume-se que uma implementação de balanceador de carga que corresponda à classe especificada esteja observando os Services. Qualquer implementação de balanceador de carga padrão (por exemplo, a fornecida pelo provedor de nuvem) ignorará Services que tenham este campo definido. spec.loadBalancerClass pode ser definido apenas em um Service do tipo LoadBalancer. Uma vez definido, não pode ser alterado. O valor de spec.loadBalancerClass deve ser um identificador no estilo de rótulo, com um prefixo opcional como "internal-vip" ou "example.com/internal-vip". Nomes sem prefixo são reservados para usuários finais.

Modo do endereço IP do balanceador de carga

Para um Service do type: LoadBalancer, um controlador pode definir .status.loadBalancer.ingress.ipMode. O .status.loadBalancer.ingress.ipMode especifica como o IP do balanceador de carga se comporta. Ele pode ser especificado apenas quando o campo .status.loadBalancer.ingress.ip também estiver especificado.

Existem dois valores possíveis para .status.loadBalancer.ingress.ipMode: "VIP" e "Proxy". O valor padrão é "VIP", significando que o tráfego é entregue ao nó com o destino definido para o IP e porta do balanceador de carga. Existem dois casos ao definir isso como "Proxy", dependendo de como o balanceador de carga do provedor de nuvem entrega o tráfego:

• Se o tráfego é entregue ao nó e então sofre DNAT para o Pod, o destino seria definido para o IP do nó e a node port;
• Se o tráfego é entregue diretamente ao Pod, o destino seria definido para o IP e porta do Pod.

Implementações de Service podem usar esta informação para ajustar o roteamento de tráfego.

Balanceador de carga interno

Em um ambiente misto, às vezes é necessário rotear o tráfego de Services dentro do mesmo bloco de endereço de rede (virtual).

Em um ambiente DNS split-horizon, você precisaria de dois Services para poder rotear tanto o tráfego externo quanto o interno para seus endpoints.

Para definir um balanceador de carga interno, adicione uma das seguintes anotações ao seu Service dependendo do provedor de serviço de nuvem que você está usando:

• Default
• GCP
• AWS
• Azure
• IBM Cloud
• OpenStack
• Baidu Cloud
• Tencent Cloud
• Alibaba Cloud
• OCI

metadata:
  name: my-service
  annotations:
    networking.gke.io/load-balancer-type: "Internal"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"

metadata:
  name: my-service
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/openstack-internal-load-balancer: "true"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true"

metadata:
  annotations:
    service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx

metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"

metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-internal: true

type: ExternalName

Services do tipo ExternalName mapeiam um Service para um nome DNS, não para um seletor típico como my-service ou cassandra. Você especifica esses Services com o parâmetro spec.externalName.

Esta definição de Service, por exemplo, mapeia o Service my-service no namespace prod para my.database.example.com:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

Ao procurar o host my-service.prod.svc.cluster.local, o Service DNS do cluster retorna um registro CNAME com o valor my.database.example.com. Acessar my-service funciona da mesma forma que outros Services, mas com a diferença crucial de que o redirecionamento acontece no nível DNS em vez de via proxy ou encaminhamento. Se você decidir posteriormente mover seu banco de dados para dentro do seu cluster, você pode iniciar seus Pods, adicionar seletores ou endpoints apropriados, e alterar o type do Service.

Headless Services

Às vezes você não precisa de balanceamento de carga e um único IP de Service. Neste caso, você pode criar o que são chamados de headless Services, especificando explicitamente "None" para o endereço IP do cluster (.spec.clusterIP).

Você pode usar um headless Service para fazer interface com outros mecanismos de descoberta de serviços, sem estar vinculado à implementação do Kubernetes.

Para headless Services, um IP de cluster não é alocado, o kube-proxy não manipula esses Services, e não há balanceamento de carga ou proxy feito pela plataforma para eles.

Um headless Service permite que um cliente se conecte a qualquer Pod que preferir, diretamente. Headless Services não configuram rotas e encaminhamento de pacotes usando endereços IP virtuais e proxies; em vez disso, Headless Services reportam os endereços IP de endpoint dos Pods individuais via registros DNS internos, servidos através do serviço DNS do cluster. Para definir um headless Service, você cria um Service com .spec.type definido como ClusterIP (que também é o padrão para type), e você adicionalmente define .spec.clusterIP como None.

O valor de string None é um caso especial e não é o mesmo que deixar o campo .spec.clusterIP não definido.

Como o DNS é configurado automaticamente depende se o Service tem seletores definidos:

Com seletores

Para headless Services que definem seletores, o controlador de endpoints cria EndpointSlices na API do Kubernetes, e modifica a configuração DNS para retornar registros A ou AAAA (endereços IPv4 ou IPv6) que apontam diretamente para os Pods que sustentam o Service.

Sem seletores

Para headless Services que não definem seletores, a camada de gerenciamento não cria objetos EndpointSlice. No entanto, o sistema DNS procura e configura um dos seguintes:

• Registros DNS CNAME para Services type: ExternalName.
• Registros DNS A / AAAA para todos os endereços IP dos endpoints prontos do Service, para todos os tipos de Service diferentes de ExternalName.
  • Para endpoints IPv4, o sistema DNS cria registros A.
  • Para endpoints IPv6, o sistema DNS cria registros AAAA.

Quando você define um headless Service sem seletor, a port deve corresponder à targetPort.

Descobrindo Services

Para clientes em execução dentro do seu cluster, o Kubernetes suporta dois modos principais de encontrar um Service: variáveis de ambiente e DNS.

Variáveis de ambiente

Quando um Pod é executado em um Node, o kubelet adiciona um conjunto de variáveis de ambiente para cada Service ativo. Ele adiciona as variáveis {SVCNAME}_SERVICE_HOST e {SVCNAME}_SERVICE_PORT, onde o nome do Service está em maiúsculas e os traços são convertidos em sublinhados.

Por exemplo, o Service redis-primary que expõe a porta TCP 6379 e recebeu o endereço IP de cluster 10.0.0.11, produz as seguintes variáveis de ambiente:

REDIS_PRIMARY_SERVICE_HOST=10.0.0.11
REDIS_PRIMARY_SERVICE_PORT=6379
REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379
REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp
REDIS_PRIMARY_PORT_6379_TCP_PORT=6379
REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11

O Kubernetes também suporta e fornece variáveis que são compatíveis com a funcionalidade "legacy container links" do Docker Engine. Você pode ler makeLinkVariables para ver como isso é implementado no Kubernetes.

DNS

Você pode (e quase sempre deveria) configurar um serviço DNS para o seu cluster Kubernetes usando um complemento.

Um servidor DNS com reconhecimento de cluster, como o CoreDNS, observa a API do Kubernetes em busca de novos Services e cria um conjunto de registros DNS para cada um. Se o DNS foi habilitado em todo o seu cluster, então todos os Pods devem ser capazes automaticamente de resolver Services por seu nome DNS.

Por exemplo, se você tem um Service chamado my-service em um namespace my-ns do Kubernetes, a camada de gerenciamento e o Service DNS atuando juntos criam um registro DNS para my-service.my-ns. Os Pods no namespace my-ns devem ser capazes de encontrar o service fazendo uma busca de nome por my-service (my-service.my-ns também funcionaria).

Pods em outros namespaces devem qualificar o nome como my-service.my-ns. Esses nomes resolverão para o IP do cluster atribuído ao Service.

O Kubernetes também suporta registros DNS SRV (Service) para portas nomeadas. Se o Service my-service.my-ns tiver uma porta chamada http com o protocolo definido como TCP, você pode fazer uma consulta DNS SRV para _http._tcp.my-service.my-ns para descobrir o número da porta para http, bem como o endereço IP.

O servidor DNS do Kubernetes é a única maneira de acessar Services ExternalName. Você pode encontrar mais informações sobre resolução ExternalName em DNS para Services e Pods.

Leia IPs Virtuais e Proxies de Service que explica o mecanismo que o Kubernetes fornece para expor um Service com um endereço IP virtual.

Políticas de tráfego

Você pode definir os campos .spec.internalTrafficPolicy e .spec.externalTrafficPolicy para controlar como o Kubernetes roteia o tráfego para backends íntegros ("prontos").

Consulte Políticas de Tráfego para mais detalhes.

Distribuição de tráfego

O campo .spec.trafficDistribution fornece outra maneira de influenciar o roteamento de tráfego dentro de um Service do Kubernetes. Enquanto as políticas de tráfego focam em garantias semânticas estritas, a distribuição de tráfego permite que você expresse preferências (como rotear para endpoints topologicamente mais próximos). Isso pode ajudar a otimizar desempenho, custo ou confiabilidade. No Kubernetes 1.35, o seguinte valor de campo é suportado:

PreferClose

Indica uma preferência por rotear o tráfego para endpoints que estão na mesma zona que o cliente.

No Kubernetes 1.35, dois valores adicionais estão disponíveis (a menos que o feature gate PreferSameTrafficDistribution esteja desabilitado):

PreferSameZone

Este é um alias para PreferClose que é mais claro sobre a semântica pretendida.

PreferSameNode

Indica uma preferência por rotear o tráfego para endpoints que estão no mesmo nó que o cliente.

Se o campo não for definido, a implementação aplicará sua estratégia de roteamento padrão.

Consulte Distribuição de Tráfego para mais detalhes.

Persistência de sessão

Se você quiser garantir que as conexões de um cliente específico sejam passadas para o mesmo Pod a cada vez, você pode configurar afinidade de sessão baseada no endereço IP do cliente. Leia afinidade de sessão para saber mais.

IPs externos

Se houver IPs externos que roteiam para um ou mais nós do cluster, os Services do Kubernetes podem ser expostos nesses externalIPs. Quando o tráfego de rede chega ao cluster, com o IP externo (como IP de destino) e a porta correspondente a esse Service, regras e rotas que o Kubernetes configurou garantem que o tráfego seja roteado para um dos endpoints desse Service.

Quando você define um Service, você pode especificar externalIPs para qualquer tipo de Service. No exemplo abaixo, o Service chamado "my-service" pode ser acessado por clientes usando TCP, em "198.51.100.32:80" (calculado a partir de .spec.externalIPs[] e .spec.ports[].port).

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 49152
  externalIPs:
    - 198.51.100.32

Objeto da API

Service é um recurso de nível superior na API REST do Kubernetes. Você pode encontrar mais detalhes sobre o objeto da API Service.

Próximos passos

Saiba mais sobre Services e como eles se encaixam no Kubernetes:

• Siga o tutorial Conectando Aplicações com Services.
• Leia sobre Ingress, que expõe rotas HTTP e HTTPS de fora do cluster para Services dentro do seu cluster.
• Leia sobre Gateway, uma extensão do Kubernetes que fornece mais flexibilidade do que o Ingress.

Para mais contexto, leia o seguinte:

• IPs Virtuais e Proxies de Service
• EndpointSlices
• Referência da API Service
• Referência da API EndpointSlice
• Referência da API Endpoint (legado)

6.2 - Ingress

Um objeto da API (do inglês "Application Programming Interface") que gerencia o acesso externo aos serviços em um cluster, normalmente HTTP.

Um Ingress pode fornecer balanceamento de carga, terminação SSL e hospedagem virtual baseada em nomes.

Terminologia

Para fins de clareza, este guia define os seguintes termos:

• Nó: Uma máquina de trabalho no Kubernetes, parte de um cluster.
• Cluster: Um conjunto de nós que executam aplicações em contêiner gerenciado pelo Kubernetes. Para este exemplo, e nas instalações mais comuns do Kubernetes, os nós no cluster não fazem parte da Internet pública.
• Roteador de borda: Um roteador que impõe a política de firewall para o seu cluster. Isso pode ser um gateway gerenciado por um provedor de nuvem ou um hardware físico.
• Rede do cluster: Um conjunto de links, lógicos ou físicos, que facilitam a comunicação dentro de um cluster de acordo com o modelo de rede do Kubernetes.
• Serviço: Um objeto serviço do Kubernetes que identifica um conjunto de Pods usando seletores de label. Salvo indicação em contrário, assume-se que os Serviços tenham IPs virtuais apenas roteáveis dentro da rede de cluster.

O que é o Ingress?

O Ingress expõe rotas HTTP e HTTPS de fora do cluster para um serviço dentro do cluster. O roteamento do tráfego é controlado por regras definidas no recurso Ingress.

Aqui está um exemplo simples em que o Ingress envia todo o seu tráfego para um serviço:

Um Ingress pode ser configurado para fornecer URLs acessíveis externamente aos serviços, balanceamento de carga de tráfego, terminação SSL/TLS e oferecer hospedagem virtual baseada em nome. Um controlador Ingress é responsável por atender o Ingress, geralmente com um balanceador de carga, embora também possa configurar seu roteador de borda ou frontends adicionais para ajudar a lidar com o tráfego.

Um Ingress não expõe portas ou protocolos arbitrários. Normalmente se usa um serviço do tipo Service.Type=NodePort ou Service.Type=LoadBalancer para expor serviços à Internet que não sejam HTTP e HTTPS.

Pré-requisitos

Você deve ter um controlador Ingress para satisfazer um Ingress. Apenas a criação de um recurso Ingress não tem efeito.

Você pode precisar instalar um controlador Ingress. Você pode escolher entre vários controladores Ingress.

Idealmente, todos os controladores Ingress devem se encaixar na especificação de referência. Na realidade, os vários controladores Ingress operam de forma ligeiramente diferente.

O recurso Ingress

Um exemplo mínimo do recurso Ingress:

service/networking/minimal-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

Um Ingress precisa dos campos apiVersion, kind, metadata e spec. O nome de um objeto Ingress deve ser um nome de subdomínio DNS válido. Para obter informações gerais sobre como trabalhar com arquivos de configuração, consulte como instalar aplicações, como configurar contêineres e como gerenciar recursos. O Ingress frequentemente usa anotações para configurar opções dependendo do controlador Ingress. Diferentes controladores Ingress suportam diferentes anotações. Revise a documentação do seu controlador Ingress escolhido para saber quais anotações são suportadas.

A especificação Ingress tem todas as informações necessárias para configurar um balanceador de carga ou servidor proxy. Mais importante ainda, ele contém uma lista de regras correspondentes a todas as solicitações recebidas. O recurso Ingress suporta apenas regras para direcionar o tráfego HTTP(S).

Se o ingressClassName for omitido, uma classe Ingress padrão deve ser definida.

Existem alguns controladores Ingress que funcionam sem a definição de uma IngressClass padrão. Recomenda-se especificar a IngressClass padrão, conforme mostrado abaixo.

Regras do Ingress

Cada regra HTTP contém as seguintes informações:

• Um host opcional. Neste exemplo, nenhum host é especificado, portanto, a regra se aplica a todo o tráfego HTTP de entrada através do endereço IP especificado. Se um host for fornecido (por exemplo, foo.bar.com), as regras se aplicam a esse host.
• Uma lista de caminhos (por exemplo, /testpath), cada um com um backend associado definido com um service.name e um service.port.name ou service.port.number. Tanto o host quanto o caminho devem corresponder ao conteúdo de uma solicitação recebida antes que o balanceador de carga direcione o tráfego para o serviço referenciado.
• Um backend é uma combinação de nomes de serviço e porta, conforme descrito na documentação de Services ou um backend de recursos personalizados por meio de um CRD. As solicitações HTTP e HTTPS para o Ingress que correspondem ao host e ao caminho da regra são enviadas para o backend listado.

Um defaultBackend geralmente é configurado em um controlador Ingress para atender a quaisquer solicitações que não correspondam a um caminho na especificação.

DefaultBackend

Um Ingress sem regras envia todo o tráfego para um único backend padrão e .spec.defaultBackend é o backend que deve lidar com as solicitações nesse caso. O defaultBackend é convencionalmente uma opção de configuração do controlador Ingress e não é especificado em seus recursos Ingress. Se nenhum .spec.rules for especificado, o .spec.defaultBackend deve ser especificado. Se o defaultBackend não for definido, o tratamento de solicitações que não correspondem a nenhuma das regras ficará a cargo do controlador de Ingress (consulte a documentação do seu controlador de Ingress para descobrir como ele lida com esse caso).

Se nenhum dos hosts ou caminhos corresponder à solicitação HTTP nos objetos Ingress, o tráfego será roteado para o seu backend padrão.

Resource backends

Um Resource backend é um ObjectRef para outro recurso Kubernetes dentro do mesmo namespace que o objeto Ingress. Um Resource é uma configuração mutuamente exclusiva com o serviço, e a validação irá falhar se ambos forem especificados. Um uso comum para um Resource backend é inserir dados em um backend de armazenamento de objetos com ativos estáticos.

service/networking/ingress-resource-backend.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-resource-backend
spec:
  defaultBackend:
    resource:
      apiGroup: k8s.example.com
      kind: StorageBucket
      name: static-assets
  rules:
    - http:
        paths:
          - path: /icons
            pathType: ImplementationSpecific
            backend:
              resource:
                apiGroup: k8s.example.com
                kind: StorageBucket
                name: icon-assets

Depois de criar o Ingress acima, você pode visualizá-lo com o seguinte comando:

kubectl describe ingress ingress-resource-backend

Name:             ingress-resource-backend
Namespace:        default
Address:
Default backend:  APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /icons   APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets
Annotations:  <none>
Events:       <none>

Tipos de path HTTP

Cada caminho no Ingress deve ter um tipo de caminho correspondente. Os caminhos que não incluem um pathType explícito falharão na validação. Existem três tipos de caminho suportados:

• ImplementationSpecific: Com esse tipo de caminho, a correspondência depende da IngressClass. As implementações podem tratar isso como um pathType separado ou tratá-lo de forma idêntica aos tipos de caminho Prefix ou Exact.
• Exact: Corresponde exatamente ao caminho da URL podendo ser case-sensitive.
• Prefix: Corresponde com base em um prefixo de caminho de URL dividido por /. A correspondência faz distinção entre maiúsculas e minúsculas e é feita em um caminho, elemento por elemento. Um elemento de caminho refere-se à lista de labels no caminho dividido pelo separador /. Uma solicitação é uma correspondência para o caminho p se cada p for um prefixo elementar de p do caminho da solicitação.

Exemplos

Várias correspondências

Em alguns casos, vários caminhos dentro de uma entrada corresponderão a uma solicitação. Nesses casos, a precedência será dada primeiro ao caminho correspondente mais longo. Se dois caminhos ainda estiverem iguais, a precedência será dada aos caminhos com um tipo de caminho exato sobre o tipo de caminho de prefixo.

Hostname curingas

Os hosts podem ter correspondências precisas (por exemplo, “foo.bar.com”) ou um curinga (por exemplo, “*.foo.com”). Correspondências precisas exigem que o cabeçalho do host HTTP corresponda ao campo host. As correspondências curinga exigem que o cabeçalho do host HTTP seja igual ao sufixo da regra curinga.

service/networking/ingress-wildcard-host.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

Classe Ingress

Os Ingress podem ser implementados por diferentes controladores, muitas vezes com diferentes configurações. Cada Ingress deve especificar uma classe, uma referência a um recurso IngressClass que contém uma configuração adicional, incluindo o nome do controlador que deve implementar a classe.

service/networking/external-lb.yaml

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb
spec:
  controller: example.com/ingress-controller
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: external-lb

O campo .spec.parameters de uma classe Ingress permite que você faça referência a outro recurso que fornece a configuração relacionada a essa classe Ingress.

O tipo específico de parâmetros a serem usados depende do controlador Ingress que você especificar no campo .spec.controller da classe Ingress.

Escopo da classe Ingress

Dependendo do seu controlador Ingress, os parâmetros definidos em todo o cluster ou apenas para um namespace poderão ser utilizados.

• Cluster
• Namespaced

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-1
spec:
  controller: example.com/ingress-controller
  parameters:
    # Os parâmetros para esta classe Ingress são especificados em um
    # ClusterIngressParameter (grupo de API k8s.example.net) nomeado
    # "external-config-1". Esta definição diz ao Kubernetes para
    # procurar um recurso de parâmetro com escopo de cluster.    
    scope: Cluster
    apiGroup: k8s.example.net
    kind: ClusterIngressParameter
    name: external-config-1

---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: external-lb-2
spec:
  controller: example.com/ingress-controller
  parameters:
    # The parameters for this IngressClass are specified in an
    # IngressParameter (API group k8s.example.com) named "external-config",
    # that's in the "external-configuration" namespace.
    scope: Namespace
    apiGroup: k8s.example.com
    kind: IngressParameter
    namespace: external-configuration
    name: external-config

Anotação obsoleta

Antes que o recurso IngressClass e o campo ingressClassName fossem adicionados no Kubernetes 1.18, as classes Ingress foram especificadas com uma anotação kubernetes.io/ingress.class no Ingress. Esta anotação nunca foi formalmente definida, mas foi amplamente apoiada pelos controladores Ingress.

O campo ingressClassName mais recente no Ingress é um substituto para essa anotação, mas não é um equivalente direto. Embora a anotação tenha sido geralmente usada para fazer referência ao nome do controlador Ingress que deve implementar o Ingress, o campo é uma referência a um recurso IngressClass que contém a configuração Ingress adicional, incluindo o nome do controlador Ingress.

Classe Ingress Padrão

Você pode marcar uma classe Ingress específica como padrão para o seu cluster. Definir a anotação ingressclass.kubernetes.io/is-default-class como true em um recurso IngressClass garantirá que novos Ingress sem um campo ingressClassName especificado sejam atribuídos a esta ingressClassName padrão.

service/networking/default-ingressclass.yaml

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
  name: example-class
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: k8s.io/example-class

Tipos de Ingress

Ingress fornecidos por um único serviço

No Kubernetes existem conceitos que permitem expor um único serviço (veja alternativas). Você também pode fazer isso com um Ingress especificando um backend padrão sem regras.

service/networking/test-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: test
      port:
        number: 80

Se você criá-lo usando kubectl apply -f, você deve ser capaz de visualizar o estado do Ingress que você adicionou:

kubectl get ingress test-ingress

NAME           CLASS         HOSTS   ADDRESS         PORTS   AGE
test-ingress   external-lb   *       203.0.113.123   80      59s

Onde 203.0.113.123 é o IP alocado pelo controlador Ingress para satisfazer o Ingress.

Simples fanout

Uma configuração de fanout roteia o tráfego de um único endereço IP para mais de um serviço, com base na URI HTTP que está sendo solicitada. Um Ingress permite que você mantenha o número de balanceadores de carga no mínimo. Por exemplo, uma configuração como:

exigiria um Ingress como:

service/networking/simple-fanout-example.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        pathType: Prefix
        backend:
          service:
            name: service1
            port:
              number: 4200
      - path: /bar
        pathType: Prefix
        backend:
          service:
            name: service2
            port:
              number: 8080

Quando você cria o Ingress com kubectl apply -f:

kubectl describe ingress simple-fanout-example

Name:             simple-fanout-example
Namespace:        default
Address:          178.91.123.132
Default backend:  default-http-backend:80 (10.8.2.3:8080)
Rules:
  Host         Path  Backends
  ----         ----  --------
  foo.bar.com
               /foo   service1:4200 (10.8.0.90:4200)
               /bar   service2:8080 (10.8.0.91:8080)
Events:
  Type     Reason  Age                From                     Message
  ----     ------  ----               ----                     -------
  Normal   ADD     22s                loadbalancer-controller  default/test

O controlador Ingress fornece um balanceador de carga específico de implementação que satisfaz o Ingress, desde que os serviços (service1, service2) existam. Quando tiver feito isso, você pode ver o endereço do balanceador de carga no campo Address.

Hospedagem virtual baseada em nome

Os hosts virtuais baseados em nomes suportam o roteamento de tráfego HTTP para vários nomes de host no mesmo endereço IP.

O Ingress a seguir diz ao balanceador de carga de apoio para rotear solicitações com base no Host header.

service/networking/name-virtual-host-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80