O que é Kubernetes?

O que é Kubernetes? E qual é a sua arquitetura?

A contêinerização cortou o cordão entre desenvolvedores de software e o ambiente de produção. Não no sentido de que você não precisa de um sistema de produção, mas não precisa se preocupar com a especificidade do ambiente de produção.

Os aplicativos agora estão agrupados com as dependências de que precisam, em um contêiner leve em vez de uma VM. Isso é ótimo! No entanto, ele não fornece imunidade a falhas do sistema, falhas de rede ou falhas de disco. Por exemplo, se o data center, onde seus servidores estiverem em execução, estiver em manutenção, seu aplicativo ficará offline.

Kubernetes entra em cena para resolver esses problemas. É preciso a idéia de contêineres e estende -a para funcionar em vários nós de computação (que podem ser a máquina virtual hospedada em nuvem ou servidores de metal nu). A idéia é ter um sistema distribuído para aplicativos de contêiner para executar.

Por que Kubernetes?

Agora, por que você precisaria ter um ambiente distribuído em primeiro lugar?

Por várias razões, primeiro e acima de tudo é alta disponibilidade. Você deseja que seu site de comércio eletrônico fique online 24 horas por dia, 7. Segundo é a escalabilidade, onde você deseja escalar '. A escala aqui envolve a adição de mais nós de computação para dar ao seu aplicativo crescente mais espaço para operar.

Design e arquitetura

Como qualquer sistema distribuído, um cluster de Kubernetes tem um nó mestre e, em seguida, muitos nós de trabalhador, que é onde seus aplicativos realmente funcionariam. O mestre é responsável por agendar tarefas, gerenciar cargas de trabalho e adicionar com segurança novos nós ao cluster.

Agora, é claro, o nó mestre em si pode falhar e levar todo o cluster com ele, então Kubernetes realmente permite que você tenha vários nós mestres por causa da redundância.

Uma visão de um pássaro de uma implantação típica de Kubernetes

Kubernetes Mestre

O Kubernetes Master é o que a equipe DevOps interage e usa para provisionar novos nós, implantar novos aplicativos e monitoramento e gerenciamento de recursos. A tarefa mais básica do nó mestre é agendar A carga de trabalho com eficiência entre todos os nós do trabalhador para maximizar a utilização de recursos, melhorar o desempenho e seguir várias políticas escolhidas pela equipe DevOps para sua carga de trabalho específica.

Outro componente importante é o etcd que é um daemon que acompanha os nós do trabalhador e mantém um banco de dados armazenando todo o estado do cluster. É um armazenamento de dados de valor-chave, que também pode ser executado em um ambiente distribuído em vários nós mestre. O conteúdo do ETCD fornece todos os dados relevantes sobre todo o cluster. Um nó do trabalhador examinaria o conteúdo do etcd de tempos em tempos para determinar como deve se comportar.

Controlador é a entidade que receberia instruções do servidor API (que abordaremos mais tarde) e executaremos ações necessárias como criação, exclusão e atualização de aplicativos e pacotes.

O Servidor API expõe a API Kubernetes, que usa cargas de pagamento JSON sobre HTTPs, para se comunicar com a interface do usuário com a qual as equipes de desenvolvedores ou o pessoal do DevOps acabariam interagindo com a interação com. Tanto a interface da web quanto a CLI consome essa API para interagir com o cluster Kubernetes.

O servidor da API também é responsável pela comunicação entre os nós do trabalhador e vários componentes do nó principal, como etcd.

O nó mestre nunca é exposto ao usuário final, pois arriscaria a segurança de todo o cluster.

Nós Kubernetes

Uma máquina (física ou virtual) precisaria de alguns componentes importantes que, uma vez instalados e configurados, podem transformar esse servidor em um membro do seu cluster Kubernetes.

A primeira coisa que você precisará é um tempo de execução de contêineres, como o Docker, instalado e executando nele. Será responsável por girar e gerenciar recipientes, obviamente.

Junto com o tempo de execução do Docker, também precisamos do Kubelet Daemon. Ele se comunica com os nós mestres, através do servidor API e consulta o etcd, e devolve informações sobre saúde e uso sobre as vagens que estão sendo executadas nesse nó.

No entanto, os contêineres são bastante limitados por si mesmos, portanto, Kubernetes tem uma abstração mais alta construída sobre uma coleção de recipientes, conhecida como Vagens.

Por que inventar pods?

Docker tem uma política de executar um aplicativo por contêiner. Frequentemente descrito como o “Um processo por contêiner” política. Isso significa que, se você precisar de um site do WordPress, é incentivado a ter dois contêineres um para o banco de dados funcionar e outro para o servidor da web executar. O agrupamento tais componentes relacionados de um aplicativo em uma vagem garante que, sempre que você escala, os dois recipientes entre dependentes sempre coexistem no mesmo nó e, assim, conversem um com o outro de maneira rápida e fácil.

As vagens são a unidade fundamental de implantação em Kubernetes. Quando você escala, você adiciona mais pods ao cluster. Cada pod recebe seu próprio endereço IP exclusivo dentro da rede interna do cluster.

De volta ao nó Kubernetes

Agora um nó pode executar várias vagens e pode haver muitos desses nós. Tudo está bem até você pensar em tentar se comunicar com o mundo externo. Se você tem um serviço simples baseado na Web, como apontaria seu nome de domínio para esta coleção de pods com muitos endereços IP?

Você não pode, e você não precisa! Kube-proxy é a peça final do quebra -cabeça que permite aos operadores expor certos pods à Internet. Por exemplo, seu front-end pode ser tornado publicamente acessível e o Kube-Proxy distribuiria o tráfego entre todos os vários pods responsáveis ​​por hospedar o front-end. Seu banco de dados, no entanto, não precisa ser tornado público e o kube-proxy permitiria apenas comunicação interna para essas cargas de trabalho relacionadas ao back-end.

Você precisa de tudo isso?

Se você está apenas começando como amador ou aluno, usar Kubernetes para um aplicativo simples seria realmente ineficiente. Toda a Rigmarole consumiria mais recursos do que o seu aplicativo real e adicionaria mais confusão para um único indivíduo.

No entanto, se você vai trabalhar com uma grande equipe e implantar seus aplicativos para uso comercial sério, o Kubernetes vale a pena a adição. Você pode impedir que as coisas fiquem caóticas. Abra espaço para manutenção sem tempo de inatividade. Configurar condições de teste A/B.