Kubernetes — Componentes

Control Plane Components

kube-apiserver

O Kube API Server é responsável por orquestrar todas as operações dentro do cluster. Ele expõe a API do Kubernetes, que é usada por usuários externos para realizar operações de gerenciamento no cluster, bem como os vários controladores para monitorar o estado do cluster e fazer as alterações necessárias conforme necessário. E pelos worker nodes para se comunicar com o servidor.

etcd

A medida de containeres sejam carregados ou descarregados, são gerados operações dentro do cluster e essas operações são gravadas em um banco, banco esse de chave e valor. Este banco dentro do nosso cluster é o etcd, nele armazenamos todos os dados do cluster.

Se o cluster do Kubernetes usar o etcd como armazenamento de backup, verifique se você tem um plano de backup para esses dados.

kube-Scheduler

É responsável por identificar o nó certo para colocar um contêiner com base nos requisitos de recursos dos contêineres, na capacidade dos worker nodes ou em quaisquer outras políticas ou restrições, como taints e tolerâncias ou regras de afinidade de nó que estão neles

kube-controller-manager

Dentro do controller manager temos numa série de componentes que permite gerenciar os recursos dentro do cluster, em termos gerais ele tem um papel de verificar a saúde dos recursos e quando necessário realizar as devidas remediações, ele é o responsável dentre as tantas responsabilidades, por verificar a saúde de um nó, de um pod, de um deployment entre outros recursos.

cloud-controller-manager (em caso de uso de serviço gerenciado)

É um componente do controlador de ciclo de vida do nó do Kubernetes. Esse componente é implantado por um DaemonSet no namespace kube-system e visa dar autonomia ao provedor de nuvem no gerenciamento do estado do recurso.

Node Components

kubelet

Um Kubelet é um agente que é executado em cada nó em um cluster. Ele ouve instruções do Kube API server e implanta ou destrói contêineres nos nós conforme necessário. O Kube API server busca periodicamente relatórios de status do Kubelet para monitorar o status de nós e contêineres neles.

kube-proxy

A medida que os aplicativos executados nos worker nodes precisam comunicar uns com os outros.

Exemplo: Você pode ter um servidor da web em execução em um contêiner em um dos nós e um servidor de banco de dados em execução em outro contêiner em outro nó.

Como o servidor web lê o servidor de banco de dados no outro nó?

A comunicação entre os worker nodes é ativada por outro componente que é executado no worker nodes conhecido como kube-proxy service. O kube-proxy service garante que as regras necessárias estejam em vigor nos worker nodes para permitir que os contêineres executados neles alcancem uns aos outros.

Container runtime

Quando estamos trabalhando com contêineres precisamos que tudo seja compatível com o contêiner. Nossas aplicações são na forma de contêineres. Os diferentes componentes que formam todo o sistema de gerenciamento no master node podem ser hospedados na forma de contêineres. A solução de rede de serviço DNS pode ser implantada na forma de contêineres. Assim sendo, precisamos desses softwares que podem executar contêineres.

E esse é o container runtime engine, um popular sendo o Docker. Portanto, precisamos do Docker ou do equivalente com suporte instalado em todos os nós do cluster, incluindo os nós mestres, se você deseja hospedar os componentes do plano de controle como contêineres. Agora, nem sempre precisa ser o Docker. O Kubernetes oferece suporte a outros mecanismos de tempo de execução, como containerd ou rocket.