Introdução
Kubernetes é um sistema de código aberto (open-source) desenvolvido inicialmente pela Google em 2014 com intuito de fazer gestão de aplicações em containers e ambientes com múltiplos servidores.
O designer do cluster kubernetes precisa seguir algumas práticas, que são:
- Seguro: Práticas de segurança avançadas de controle;
- Operação: Fácil a utilização com alguns comandos;
- Adaptável: Não poderá favorecer um fornecedor e ser configurável por meio de um arquivo.
Um administrador do Kubernetes tem a liberdade de gerir as suas aplicações sem restrições. O comportamento da aplicação de forma interna ou externa é devidamente configurável. Podendo ser feito o escalonamento, configuração de rede, atualização da aplicação, ou até reverter atualizações. E essas são algumas das possibilidades do que poderia ser feito dentro do kubernetes.
Componentes
Para uma implantação do kubernetes é necessário um maquina, ou várias, a depender da sua configuração, esse recurso é chamado de master. Este servidor tem nas suas funcionalidades uma porta de entrada (gateway) com o propósito de expor as suas APIs para que integradores verifiquem o estado dos servidores. Os integradores podem analisar as informações com a finalidade decidir a melhor forma de atribuir funções dentro do kubernetes. Segue abaixo os seus componentes.
Control panel
O componente control pane é responsável por gerir os nós de forma global. É o componente de maior relevância no kubernetes, pois gerencia as funcionalidades, e executa com perfeição.
Por exemplo, inicia um novo pod, caso ocorra um erro na réplica.
Kube-apiserver
Este componente é responsável por disponibilizar API do tipo REST para que outros recursos possam se cumunicar entre si. Essa comunicação acontece por meio da ferramenta kubectl, com objetivo de administrar o kubernetes. O kube-apiserver foi formulado para escalonar horizontalmente conforme a sua utilização.
etcd
Este componente é responsável por salvar o estado e as configurações do cluster kubernetes em formato de chave e valor, sendo consistente, e com alta disponibilidade. O etcd é manipulado por API de forma simples, com intuito de disponibilizar as configurações dos nós. Por questão de segurança o etcd é executado em nós do tipo master, ou em cluster externos.
kube-scheduler
Esse componente é responsável por atribuir pods recém-criado ao nó. A escolha para atribuição do nó é com base na quantidade de recurso disponível, e o estado do nó. O kube-scheduler entende a capacidade total de todos os nós e clusters nos recurso computacionais. E tem o propósito de garantir a alocação dos pods de forma simples para o recurso disponível. A consideração para alocação de carga leva em conta as políticas definidas pelo administrador, tais como afinidade, definição de “software” e etc.
kube-controller-manager
Esse componente é responsável por executar o cluster enquanto os controladores de gerenciamento do kubernetes executam varias funções de maneira unificada, como forma de garantir o último estado definido no etcd. O componente permiti que o kubernetes faça a interação de diversos provedores, com diferentes capacidades, recurso e APIS, enquanto faz a construção internamente.
Por exemplo: Caso esteja a executar um deploy, e nele ter 10 ReplicaSet em um pod, kube-controller-manager é responsável por verificar se todos subiram ou não.
Temos os seguintes controladores:
- Controlador do nó: responsável por identificar se o estado do nó está ativos ou não;
- Controlador de trabalho (job): responsável por observar e criar os pods para executar tarefas até finalização da sua execução;
- Controlador de endpoints: responsável pelo objeto do endpoints e a sua junção para a comunicação entre serviços e pod;
- Controlador autenticação: responsável por criar as contas de autenticação usando padrões de tokens para acesso de API e gerência de novos namespaces.
cloud-controller-manager
Esse componente é responsável por gerir a lógica da nuvem, permitindo o vínculo do cluster API no seu provedor de nuvem, com o intuito de separar os componentes de tal forma que possam interagir com a plataforma utilizada. Vale salientar que, caso esteja operando em maquina local esse recurso não estará disponível para uso.
Existem dependências para o provedor, que são:
- Controlador de nó: responsável pela verificação de nós, caso algum pare de responder;
- Controlador de rota: responsável pela gerência das rotas de infraestrutura da nuvem;
- Controlador de serviço: responsável pela gerência e balanceamento de carga no provider de nuvem.
Kubelet
Esse componente é responsável por replicar informações para o control plane e interagir com o etcd para leitura e escrita de novos valores. Em cada nó do cluster deverá existir um agente do kubelet em execução para poder gerir os pods que foram direcionados para o kube-controller-manager com o intuito de manter os containers funcionando conforme esperado. Vale ressaltar que, o kubelet não gerência containers que não são criados pelo kubernetes.
Kube-proxy
Esse componente é executado em todos os nós com a finalidade de gerir as sub-redes dos hosts. Para garantir que os serviços estejam acessíveis e isolados para outros componentes. O kube-proxy se comporta como filtro de pacote interno do sistema( caso exista um), caso contrário, o mesmo tem autonomia para encaminhar os pacotes.
Container runtime
Esse componente é responsável por conduzir e executar containers em ambiente operacional relativamente isolado, e mais leve. O kubernetes administra diversos agentes para execução de containers, que são:
O mesmo também implementa qualquer outro container que siga o CRI (Container Runtime Interface).
Addons
O addons é uma extensão de funcionalidade do kubernetes que utiliza alguns recursos como DaemonSet e Deployment. E tem como propósito implementar novas aplicações ao cluster. Esses recursos criados na namespace pertencem ao kube-system. Segue alguns addons que podem ser úteis para o cluster:
Existe uma lista de addons para administração de cluster disponível aqui.
Ferramentas para estudo
O kubernetes tem no seu modelo vários servidores como master e workers, a junção de ambos se caracteriza como um cluster. Para o funcionamento do mesmo é recomendável que exista três nós, sendo divididos em:
- Master: responsável por gerenciar o cluster;
- Worker: responsável por executar as aplicações que alocamos dentro do kubernetes.
Soluções que podemos utilizar para que não seja necessário criar os 3 nós, segue abaixo:
Então é isso galera, espero que tenham gostado, até a próxima!
Referências
https://www.digitalocean.com/community/tutorials/uma-introducao-ao-kubernetes-pt https://www.redhat.com/pt-br/topics/containers/kubernetes-architecture https://kubernetes.io/pt-br/docs/concepts/overview/components/#container-runtime https://kubernetes.io/docs/concepts/cluster-administration/logging/ https://livro.descomplicandokubernetes.com.br/pt/day_one/descomplicando_kubernetes.html