Como funciona o Kubernetes

Concluído

Uma instalação do Kubernetes configurada com sucesso depende de uma boa compreensão da arquitetura do sistema de Kubernetes. Aqui, você analisa todos os componentes que compõem uma instalação do Kubernetes.

O que é um cluster de computadores?

Um cluster é um conjunto de computadores que você configura para trabalharem em conjunto e serem vistos como um sistema. Os computadores configurados no cluster manipulam os mesmos tipos de tarefas. Por exemplo, todos eles hospedarão sites e APIs ou executarão um trabalho de computação intensiva.

Um cluster usa um software centralizado que é responsável por agendar e controlar essas tarefas. Os computadores de um cluster que executam as tarefas são chamados de nós e os computadores que executam o software de agendamento são chamados de painéis de controle.

Arquitetura do Kubernetes

Lembre-se de que um orquestrador é um sistema que implanta e gerencia aplicativos. Você também aprendeu que um cluster é um conjunto de computadores que trabalham juntos e são exibidos como um único sistema. Você usa o Kubernetes como a orquestração e o software de cluster para implantar seus aplicativos e responder a alterações nas necessidades de recursos de computação.

Um cluster do Kubernetes contém, pelo menos, um painel principal e um ou mais nós. Tanto os painéis de controle quanto as instâncias de nós podem ser dispositivos físicos, máquinas virtuais ou instâncias na nuvem. O sistema operacional do host padrão no Kubernetes é o Linux, com suporte padrão para cargas de trabalho baseadas em Linux.

Você também pode executar cargas de trabalho da Microsoft utilizando o Windows Server 2019 ou posterior em nós de cluster. Por exemplo, suponha que o serviço de processamento de dados no aplicativo de rastreamento de drones seja gravado como um aplicativo .NET 4.5 que utiliza chamadas específicas da API do SO Windows. Esse serviço só pode ser executado em nós que executam um sistema operacional Windows Server.

Agora, vamos examinar mais detalhadamente os painéis de controle e os nós de trabalho, bem como o software executado em cada um deles. Entender a função de cada componente e o local em que eles são executados no cluster é útil na hora de instalar o Kubernetes.

Painel de controle do Kubernetes

O painel de controle do Kubernetes em um cluster do Kubernetes executa uma coleção de serviços que gerencia a funcionalidade de orquestração no Kubernetes.

Do ponto de vista de aprendizado, faz sentido usar um só painel de controle no ambiente de teste enquanto você explora a funcionalidade do Kubernetes. No entanto, em implantações de produção e nuvem, como o Serviço de Kubernetes do Azure (AKS), você descobre que a configuração preferencial é uma implantação de alta disponibilidade com três a cinco planos de controle replicados.

Observação

O fato de um painel de controle executar um software específico para manter o estado do cluster não o isenta da execução de outras cargas de trabalho de computação. No entanto, de modo geral, o ideal é isentar o painel de controle de executar cargas de trabalho não críticas e de aplicativos do usuário.

Nó do Kubernetes

Um nó em um cluster do Kubernetes é o local em que as cargas de trabalho de computação são executadas. Cada nó se comunica com o painel de controle por meio do servidor de API para informar sobre as alterações de estado do nó.

Serviços executados em um painel de controle

O Kubernetes se baseia em vários serviços administrativos em execução no painel de controle. Esses serviços gerenciam aspectos como a comunicação entre os componentes do cluster, o agendamento da carga de trabalho e a persistência do estado do cluster.

Os serviços a seguir compõem o plano de controle de um cluster Kubernetes:

• O servidor de API
• O repositório de backup
• O agendador
• O gerenciador do controlador
• O gerenciador do controlador de nuvem

O que é o servidor de API?

Você pode pensar no servidor de API como o front-end para o plano de controle do seu cluster do Kubernetes. Toda a comunicação entre os componentes do Kubernetes é realizada por meio dessa API.

Por exemplo, como usuário, você utiliza um aplicativo de linha de comando chamado kubectl que permite executar comandos no servidor de API do seu cluster do Kubernetes. O componente que fornece essa API é denominado kube-apiserver, e é possível implantar várias instâncias desse componente para dar suporte ao dimensionamento no cluster.

Essa API expõe uma API RESTful que permite postar comandos ou arquivos de configuração baseados em YAML. YAML é um padrão de serialização de dados legível por humanos para linguagens de programação. Você usa arquivos YAML para definir o estado pretendido de todos os objetos de um cluster do Kubernetes.

Por exemplo, suponha que você deseje aumentar o número de instâncias do seu aplicativo no cluster. Você define o novo estado com um arquivo baseado em YAML e envia esse arquivo para o servidor de API. O servidor de API valida a configuração, salva-a no cluster e, por fim, aplica o aumento configurado nas implantações do aplicativo.

O que é o repositório de backup?

O repositório de backup é um armazenamento persistente no qual o cluster do Kubernetes salva as próprias configurações concluídas. O Kubernetes usa um repositório de chave-valor confiável, distribuído e de alta disponibilidade chamado etcd. Esse repositório de chave-valor armazena o estado atual e o estado desejado de todos os objetos do cluster.

Em um cluster de produção do Kubernetes, as diretrizes oficiais do Kubernetes são ter de três a cinco instâncias replicadas do banco de dados etcd para alta disponibilidade.

Observação

etcd não é responsável pelo backup de dados. É sua responsabilidade verificar se um plano de backup eficaz está em vigor para fazer backup dos dados de etcd.

O que é o agendador?

O agendador é o componente responsável pela atribuição de cargas de trabalho em todos os nós. O agendador monitora o cluster em busca de contêineres recém-criados e os atribui aos nós.

O que é o gerenciador do controlador?

O gerenciador do controlador inicia e monitora os controladores configurados para um cluster por meio do servidor de API.

O Kubernetes utiliza controladores para rastrear os estados dos objetos no cluster. Cada controlador é executado em um loop sem fim enquanto inspeciona e responde a eventos no cluster. Por exemplo, há controladores para monitorar nós, contêineres e pontos de extremidade.

O controlador se comunica com o servidor de API para determinar o estado do objeto. Se o estado atual for diferente do estado desejado do objeto, o controlador tomará medidas para garantir o estado desejado.

Suponha que um dos três contêineres em execução no seu cluster pare de responder e falhe. Nesse caso, um controlador decide se é necessário iniciar novos contêineres para garantir que os seus aplicativos fiquem sempre disponíveis. Se o estado desejado for executar três contêineres a qualquer momento, um novo contêiner será agendado para execução.

O que é o gerenciador do controlador de nuvem?

O gerenciador do controlador de nuvem se integra às tecnologias de nuvem subjacentes do cluster quando ele está em execução em um ambiente de nuvem. Esses serviços podem ser balanceadores de carga, filas e armazenamento, por exemplo.

Serviços executados em um nó

Há vários serviços que são executados em um nó do Kubernetes para controlar como as cargas de trabalho são executadas.

Os seguintes serviços são executados no nó do Kubernetes:

• Kubelet
• Kube-proxy
• Runtime de contêiner

O que é o kubelet?

O kubelet é o agente executado em cada nó no cluster e monitora as solicitações de trabalho do servidor de API. Ele verifica se a unidade de trabalho solicitada está em execução e é íntegra.

O kubelet monitora os nós e verifica se os contêineres agendados em cada nó são executados conforme o esperado. O kubelet gerencia apenas os contêineres que o Kubernetes cria. Ele não será responsável pelo reagendamento de trabalhos a serem executados em outros nós se o nó atual não puder executar o trabalho.

O que é o kube-proxy?

O componente kube-proxy é responsável pela rede de cluster local e é executado em cada nó. Ele verifica se cada nó tem um endereço IP exclusivo. Ele também implementa as regras para manipular o roteamento e o balanceamento de carga de tráfego usando iptables e IPVS.

Esse proxy não fornece serviços de DNS por si só. Um complemento de cluster de DNS baseado no CoreDNS é recomendado e instalado por padrão.

O que é o runtime de contêiner?

O runtime de contêiner é o software subjacente que executa contêineres em um cluster do Kubernetes. O runtime é responsável por buscar, iniciar e interromper imagens de contêiner. O Kubernetes dá suporte a vários runtimes de contêiner, incluindo, mas não limitados ao Docker, containerd, rkt, CRI-O e frakti. O suporte para muitos tipos de runtime de contêiner é baseado na CRI (Interface de Runtime de Contêiner). A CRI é um design de plug-in que permite que o kubelet se comunique com o runtime de contêiner disponível.

O runtime de contêiner padrão no AKS é o containerd, um runtime de contêiner padrão do setor.

Interagir com um cluster do Kubernetes

O Kubernetes fornece uma ferramenta de linha de comando chamada kubectl para gerenciar o cluster. Use kubectl para enviar comandos ao painel de controle do cluster ou para obter informações sobre todos os objetos do Kubernetes por meio do servidor de API.

kubectl usa um arquivo de configuração que inclui as seguintes informações de configuração:

• A configuração de Cluster especifica um nome para o cluster, as informações de certificado e o ponto de extremidade da API de serviço associado ao cluster. Essa definição permite que você se conecte de uma única estação de trabalho a vários clusters.
• A configuração de Usuário especifica os usuários e os níveis de permissão deles ao acessar os clusters configurados.
• A configuração de Contexto agrupa clusters e usuários usando um nome amigável. Por exemplo, você pode ter um "dev-cluster" e um "prod-cluster" para identificar seus clusters de desenvolvimento e de produção.

É possível configurar kubectl para se conectar a vários clusters fornecendo o contexto correto como parte da sintaxe da linha de comando.

Pods do Kubernetes

Um pod representa uma só instância de um aplicativo em execução no Kubernetes. As cargas de trabalho executadas no Kubernetes são aplicativos em contêineres. Ao contrário de um ambiente do Docker, não é possível executar os contêineres diretamente no Kubernetes. Você agrupa o contêiner em um objeto do Kubernetes chamado pod. Um pod é o menor objeto que pode ser criado no Kubernetes.

Um pod individual pode armazenar um grupo de um ou mais contêineres. No entanto, um pod normalmente não contém múltiplos do mesmo aplicativo.

Um pod inclui informações sobre o armazenamento compartilhado e a configuração de rede e uma especificação sobre como executar seus contêineres empacotados. Você usa modelos de pod para definir as informações sobre os pods que são executados no cluster. Os modelos de pod são arquivos codificados em YAML que você reutiliza e inclui em outros objetos para gerenciar as implantações de pod.

Por exemplo, digamos que você queira implantar um site em um cluster do Kubernetes. Você criará o arquivo de definição do pod que especificará a configuração e as imagens de contêiner do aplicativo. Em seguida, você implantará o arquivo de definição do pod no Kubernetes.

É improvável que um aplicativo Web tenha um site como o único componente na solução. Um aplicativo Web normalmente tem algum tipo de armazenamento de dados e outros elementos de suporte. Os pods do Kubernetes também podem conter mais de um contêiner.

Suponha que o seu site use um banco de dados. O site é empacotado no contêiner principal, e o banco de dados é empacotado no contêiner de suporte. Vários contêineres se comunicam entre si por meio de um ambiente. Os contêineres incluem serviços para um sistema operacional host, pilha de rede, namespace de kernel, memória compartilhada e volume de armazenamento. O pod é o ambiente de área restrita que fornece todos esses serviços para seu aplicativo. O pod também permite que os contêineres compartilhem o endereço IP atribuído dele.

Como você pode eventualmente criar muitos pods que estão sendo executados em muitos nós, pode ser difícil identificá-los. Você pode reconhecer e agrupar pods utilizando rótulos de caracteres que especifica ao definir um pod.

Ciclo de vida de um pod do Kubernetes

Os pods do Kubernetes têm um ciclo de vida distinto que afeta a maneira como você implanta, executa e atualiza os pods. Você começa enviando o manifesto YAML do pod para o cluster. Depois que o arquivo de manifesto é enviado e persistido no cluster, ele definirá o estado desejado do pod. O agendador agenda o pod para um nó íntegro com recursos suficientes para executar o pod.

Estas são as fases do ciclo de vida de um pod:

Fase	Descrição
Pendente	O pod aceita o cluster, mas nem todos os contêineres no cluster estão configurados ou prontos para execução. O status pendente indica o tempo que um pod está aguardando para ser agendado e o tempo gasto baixando imagens de contêiner.
Em execução	O pod faz a transição para um estado de execução depois que todos os recursos dentro do pod estão prontos.
Com sucesso	O pod faz a transição para o estado com sucesso depois que o pod conclui a tarefa pretendida e é executado com sucesso.
Com falha	Os pods podem falhar por vários motivos. Um contêiner no pod falhar, levando ao encerramento de todos os outros contêineres, ou talvez uma imagem não tenha sido encontrada durante a preparação dos contêineres do pod. Nesses tipos de casos, o pod pode entrar em um estado de falha. Os pods podem fazer a transição para um estado De falha a partir de um estado Pendente ou em Execução. Uma falha específica também pode colocar um pod de volta ao estado pendente.
Desconhecido	Se o estado do pod não puder ser determinado, o pod estará em um estado Desconhecido.

Os pods são mantidos em um cluster até que um controlador, o painel de controle ou um usuário os removam explicitamente. Quando um pod é excluído, um novo pod é criado imediatamente depois. O novo pod é considerado uma instância totalmente nova com base no manifesto do pod. Não é uma cópia exata, portanto, é diferente do pod excluído.

O cluster não salva o estado do pod ou a configuração atribuída dinamicamente. Por exemplo, ele não salva a ID ou o endereço IP do pod. Esse aspecto afeta a maneira como você implanta os pods e como você projeta seus aplicativos. Por exemplo, você não pode contar com endereços IP pré-atribuídos para seus pods.

Estados do contêiner

Tenha em mente que as fases são um resumo do ponto em que o pod está em seu ciclo de vida. Quando você inspeciona um pod, o cluster usa três estados para acompanhar seus contêineres dentro do pod:

Estado	Descrição
Aguardando	Estado padrão de um contêiner e o estado em que o contêiner se encontra quando não está Em execução e nem Encerrado.
Em execução	O contêiner está sendo executado conforme o esperado sem problemas.
Terminado	O contêiner não está mais em execução. O motivo é que todas as tarefas foram concluídas ou o contêiner falhou por algum motivo. Um motivo e um código de saída estão disponíveis para depurar ambos os casos.