Como funciona o Kubernetes

Concluído

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

O que é um cluster de cálculo?

Um cluster é um conjunto de computadores que configuramos para trabalhar em conjunto e ver como um único sistema. Os computadores configurados no cluster lidam com os mesmos tipos de tarefas. Por exemplo, todos alojam sites, APIs ou executam tarefas de computação intensiva.

Um cluster utiliza software centralizado que é responsável pelo agendamento e o controlo destas tarefas. Os computadores num cluster que executam as tarefas chamam-se nós e os computadores que executam o agendamento de software chamam-se planos de controlo.

Arquitetura do Kubernetes

Relembramos que um orquestrador é um sistema que implementa e gere aplicações. Você também aprendeu que um cluster é um conjunto de computadores que trabalham juntos e são vistos como um único sistema. Utilizamos o Kubernetes como orquestração e o software do cluster para implementar as aplicações e responder a alterações nas necessidades dos recursos de computação.

Um cluster do Kubernetes tem, pelo menos, um plano principal e um ou mais nós. Os planos de controlo e as instâncias de nós podem ser dispositivos físicos, máquinas virtuais ou instâncias na cloud. O SO anfitrião predefinido no Kubernetes é o Linux, com suporte predefinido para cargas de trabalho baseadas no Linux.

Você também pode executar cargas de trabalho da Microsoft usando 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 é escrito como um aplicativo .NET 4.5 que usa chamadas específicas de API do sistema operacional Windows. Este serviço só pode ser executado em nós com um SO do Windows Server.

Agora, vamos examinar os planos de controle e nós de trabalho e o software que é executado em cada um deles com mais detalhes. Compreender a função de cada componente e onde cada componente é executado no cluster é essencial para instalar o Kubernetes.

Plano de controlo do Kubernetes

O plano de controlo num cluster do Kubernetes executa uma coleção de serviços que gere a funcionalidade de orquestração no Kubernetes.

De uma perspetiva de aprendizagem, faz sentido utilizar um único nó principal no seu ambiente de teste à medida que explora as funcionalidades do Kubernetes. No entanto, em implantações de produção e de nuvem, como o Serviço Kubernetes do Azure (AKS), você descobre que a configuração preferida é uma implantação de alta disponibilidade com três a cinco planos de controle replicados.

Nota

O facto de um plano de controlo executar um software específico para manter o estado do cluster não o impede de executar outras cargas de trabalho de computação. No entanto, normalmente, recomenda-se que exclua a possibilidade de o plano de controlo executar cargas de trabalho de aplicação de utilizador e não prioritárias.

Nó do Kubernetes

Um nó num cluster do Kubernetes é onde as suas cargas de trabalho de computação são executadas. Cada nó comunica com o plano de controlo através do servidor de API para o informar acerca das alterações de estado no nó.

Serviços executados num plano de controlo

O Kubernetes depende de vários serviços administrativos a serem executados no plano de controlo. Esses serviços gerenciam aspetos como comunicação de componentes de cluster, agendamento de carga de trabalho e persistência de estado de cluster.

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

• Servidor de API
• Armazenamento de segurança
• Agendador
• Gestor do controlador
• Gestor do controlador da cloud

O que é o servidor de API?

Você pode pensar no servidor de API como o front-end do plano de controle do cluster Kubernetes. Toda a comunicação entre os componentes no Kubernetes é feita através desta API.

Por exemplo, como usuário, você usa um aplicativo de linha de comando chamado kubectl que permite executar comandos no servidor de API do cluster Kubernetes. O componente que fornece esta API chama-se kube-apiserver e pode implementar várias instâncias deste componente para suportar o dimensionamento no seu cluster.

Esta API expõe uma API RESTful que pode utilizar para publicar comandos ou ficheiros de configuração baseados em YAML. YAML é um padrão de serialização de dados legíveis por humanos para linguagens de programação. Utilizamos ficheiros YAML para definir o estado pretendido de todos os objetos num cluster do Kubernetes.

Por exemplo, imagine que pretende aumentar o número de instâncias da sua aplicação 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, finalmente, executa o aumento configurado nas implantações de aplicativos.

O que é o armazenamento de segurança?

O armazenamento de backup é um armazenamento persistente no qual o cluster Kubernetes salva sua configuração concluída. O Kubernetes utiliza um arquivo de chave-valor fiável e distribuído com elevada disponibilidade chamado etcd. Este arquivo de chave-valor armazena o estado atual e o estado pretendido de todos os objetos no seu cluster.

Na produção de um cluster do Kubernetes, a orientação oficial do Kubernetes é ter três a cinco instâncias replicadas da base de dados do etcd para elevada disponibilidade.

Nota

O etcd não é responsável pela cópia de segurança de dados. Garantir que está implementado um plano de cópia de segurança eficaz para criar a cópia de segurança de dados do etcd é da sua responsabilidade.

O que é o Scheduler?

O Scheduler é um componente responsável pela atribuição de cargas de trabalho em todos os nós. O Scheduler monitoriza o cluster para novos contentores criados e atribui-os aos nós.

O que é o gestor do controlador?

O gestor do controlador inicia e monitoriza os controladores configurados para um cluster através do servidor de API.

O Kubernetes usa controladores para rastrear estados de objetos no cluster. Cada controlador é executado em um loop não terminativo enquanto observa e responde a eventos no cluster. Por exemplo, existem controladores para monitorizar nós, contentores e pontos finais.

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 cluster pare de responder e falhe. Neste caso, um controlador decide se é necessário iniciar novos contentores para garantir que as suas aplicações estão sempre disponíveis. Se o estado pretendido é executar três contentores a qualquer altura, será agendado um novo contentor para ser executado.

O que é o gestor do controlador da cloud?

O gestor do controlador da cloud integra-se com as tecnologias subjacentes à cloud no seu cluster quando o cluster estiver em execução num ambiente na cloud. Por exemplo, estes serviços podem ser balanceadores de carga, filas e armazenamento.

Serviços executados num 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 serviços seguintes são executados no nó do Kubernetes:

• Kubelet
• Kube-proxy
• Tempo de execução do contentor

O que é o kubelet?

O kubelet é o agente executado em cada nó no cluster e monitoriza os pedidos de trabalho a partir do servidor de API. Garante que a unidade de trabalho pedida está em execução e em bom estado de funcionamento.

O kubelet monitoriza os nós e garante que os contentores agendados em cada nó são executados como esperado. O kubelet gerencia apenas contêineres criados pelo Kubernetes. Não é responsável por reagendar trabalho para ser executado noutros nós se o nó atual não puder executar o trabalho.

O que é o kube-proxy?

O componente kube-proxy é responsável pelas redes do cluster local e é executado em cada nó. Garante que cada nó tem um endereço IP exclusivo. Também implementa regras para processar o encaminhamento e balanceamento de carga do tráfego com IPTABLES e IPVS.

Este proxy não fornece serviços DNS sozinho. O suplemento DNS de um cluster baseado em CoreDNS é recomendado e instalado por predefinição.

O que é o tempo de execução do contentor?

O tempo de execução do contentor é o software subjacente que executa contentores num cluster do Kubernetes. O tempo de execução é responsável por obter, iniciar e parar as imagens de contentor. O Kubernetes suporta vários tempos de execução de contêiner, incluindo, entre outros, Docker, containerd, rkt, CRI-O e frakti. O suporte para muitos tipos de tempo de execução do contentor é baseado no Container Runtime Interface (CRI). O CRI é um modelo de plug-in que permite ao kubelet comunicar com o runtime do contentor disponível.

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

Interagir com um cluster do Kubernetes

O Kubernetes fornece uma ferramenta de linha de comandos chamada kubectl para gerir o seu cluster. Pode utilizar o kubectl para enviar comandos para o plano de controlo do cluster ou obter informações acerca de todos os objetos do Kubernetes através do servidor de API.

O kubectl utiliza um ficheiro de configuração que inclui as seguintes informações de configuração:

• A configuração do Cluster especifica um nome para o cluster, informações de certificados e o ponto final da API do 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 do Utilizador especifica os utilizadores e os respetivos níveis de permissões quando acedem aos clusters configurados.
• A configuração de contexto agrupa clusters e usuários usando um nome amigável. Por exemplo, pode ter um "dev-cluster" e um "prod-cluster" para identificar os seus clusters de desenvolvimento e produção.

Pode configurar o kubectl para ligar a múltiplos clusters ao fornecer o contexto correto como parte da sintaxe da linha de comandos.

Pods do Kubernetes

Um pod representa uma única instância de uma aplicação a ser executada no Kubernetes. As cargas de trabalho que executa no Kubernetes são aplicações em contentores. Ao contrário do que acontece num ambiente do Docker, não pode executar contentores diretamente no Kubernetes. Tem de empacotar o contentor num objeto do Kubernetes chamado de pod. Um pod é o objeto mais pequeno que pode criar no Kubernetes.

Um único pod tem a capacidade de ter um grupo de um ou mais contentores. No entanto, normalmente, um pod não contém múltiplos da mesma aplicação.

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. Pode utilizar modelos de pod para definir as informações sobre os pods que são executados no seu cluster. Os modelos de pod são ficheiros codificados com YAML que pode reutilizar e incluir noutros objetos para gerir as implementações de pods.

Por exemplo, digamos que você queira implantar um site em um cluster do Kubernetes. Irá criar o ficheiro de definição do pod que especifica as imagens de contentor e configuração da aplicação. Em seguida, irá implementar o ficheiro de definição do pod no Kubernetes.

É improvável que uma aplicação Web tenha um site como único componente na solução. Normalmente, uma aplicação Web tem algum tipo de arquivo de dados e outros elementos de suporte. Os pods do Kubernetes também podem ter mais do que um contentor.

Imagine que o seu site utiliza uma base de dados. O site está empacotado no contentor principal e a base de dados no contentor 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 do kernel, memória compartilhada e volume de armazenamento. O pod é o ambiente sandbox que fornece todos estes serviços à sua aplicação. O pod também permite aos contentores partilhar o seu endereço IP atribuído.

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

Ciclo de vida de um pod do Kubernetes

Os pods do Kubernetes têm um ciclo de vida diferente que afeta a forma como implementa, executa e atualiza pods. Começa por submeter o manifesto YAML do pod para o cluster. Depois que o arquivo de manifesto é enviado e persiste no cluster, ele define o estado desejado do pod. O Scheduler agenda o pod para um nó em bom estado de funcionamento que tem recursos suficientes para executá-lo.

Eis as fases do ciclo de vida de um pod:

Fase	Description
Pendente	O pod aceita o cluster, mas nem todos os contêineres no cluster estão configurados ou prontos para serem executados. O status Pendente indica o tempo que um pod está esperando para ser agendado e o tempo gasto no download de imagens de contêiner.
Em Execução	O pod passa ao estado "Em execução" quando todos os recursos dentro do mesmo estão prontos.
Com êxito	O pod passa ao estado "Com êxito" quando conclui a sua tarefa pretendida e é executado com êxito.
Com falhas	Os pods podem falhar por vários motivos. Um contêiner no pod pode 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 ir para um estado Falhado. Os pods podem fazer a transição para um estado Failed de um estado Pending ou Running. Uma falha específica também pode fazer com que um pod regresse ao estado "Pendente".
Desconhecido	Se o estado do pod não puder ser determinado, ele estará em um estado Desconhecido.

Os pods são mantidos num cluster até serem explicitamente removidos por um controlador, pelo plano de controlo ou por um utilizador. 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, por isso difere do pod excluído.

O cluster não guarda o estado ou a configuração dinamicamente atribuída do pod. Por exemplo, não guarda o ID ou endereço IP do pod. Este fator afeta a forma como implementa pods e cria as suas aplicações. Por exemplo, não pode depender de endereços IP pré-atribuídos para os seus pods.

Estados do contentor

Tenha em atenção que as fases são um resumo do estado do pod em termos do seu ciclo de vida. Quando inspeciona um pod, o cluster utiliza três estados para controlar os seus contentores dentro do pod:

Condição	Description
A aguardar	O estado predefinido de um contentor e o estado em que o contentor está quando não está em execução ou não foi terminado.
Em Execução	O contentor está a ser executado conforme esperado, sem quaisquer problemas.
Terminado	O contentor já não está em execução. Tal acontece porque todas as tarefas foram concluídas ou porque o contentor falhou por algum motivo. Está disponível um motivo e um código de saída na depuração de ambos os casos.