Phenquestions
O que é Kubernetes? E qual é a sua arquitetura?
A conteinerização cortou o cordão entre os desenvolvedores de software e o ambiente de produção. Não no sentido de que você não precise de um sistema de produção, mas não precisa se preocupar com a especificidade do ambiente de produção.
Os aplicativos agora sã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 contra falhas do sistema, falha de rede ou falhas de disco. Por exemplo, se o data center, onde seus servidores estão rodando, estiver em manutenção, seu aplicativo ficará offline.
O Kubernetes entra em cena para resolver esses problemas. Ele pega a ideia de contêineres e a estende para funcionar em vários nós de computação (que podem ser máquinas virtuais hospedadas em nuvem ou servidores bare metal). A ideia é ter um sistema distribuído para que aplicativos em contêiner sejam executados em.
Por que o Kubernetes?
Agora, por que você precisa ter um ambiente distribuído em primeiro lugar?
Por vários motivos, em primeiro lugar é a alta disponibilidade. Se você quiser que seu site de comércio eletrônico fique online 24 horas por dia, 7 dias por semana, ou perderá negócios, use o Kubernetes para isso. O segundo é a escalabilidade, onde você deseja escalar 'para fora'. O dimensionamento aqui envolve a adição de mais nós de computação para dar ao seu aplicativo em crescimento mais espaço para operar.
Design e Arquitetura
Como qualquer sistema distribuído, um cluster do Kubernetes tem um nó mestre e, em seguida, uma grande quantidade de nós de trabalho que é onde seus aplicativos seriam realmente executados. O mestre é responsável por agendar tarefas, gerenciar cargas de trabalho e adicionar com segurança novos nós ao cluster.
Agora, é claro, o próprio nó mestre pode falhar e levar todo o cluster com ele, então o Kubernetes realmente permite que você tenha vários nós mestre para fins de redundância.
Uma visão panorâmica de uma implantação típica do Kubernetes
Mestre do Kubernetes
O mestre do Kubernetes é o que a equipe DevOps interage e usa para provisionar novos nós, implantar novos aplicativos e monitorar e gerenciar recursos. A tarefa mais básica do nó mestre é cronograma a carga de trabalho de forma eficiente entre todos os nós de trabalho para maximizar a utilização de recursos, melhorar o desempenho e seguir várias políticas escolhidas pela equipe de DevOps para sua carga de trabalho específica.
Outro componente importante é o etcd que é um daemon que rastreia os nós de trabalho e mantém um banco de dados que armazena 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 mestres. O conteúdo do etcd fornece todos os dados relevantes sobre todo o cluster. Um nó de trabalho examinaria o conteúdo do etcd de tempos em tempos para determinar como ele deveria se comportar.
Controlador é a entidade que receberia instruções do servidor API (que abordaremos mais tarde) e executaria as 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 payloads JSON sobre HTTPS, para se comunicar com a interface do usuário com a qual as equipes de desenvolvedores ou DevOps acabariam interagindo. Tanto a IU da Web quanto a CLI consomem essa API para interagir com o cluster Kubernetes.
O servidor API também é responsável pela comunicação entre os nós de trabalho e vários componentes do nó mestre, como etcd.
O nó mestre nunca é exposto ao usuário final, pois isso colocaria em risco a segurança de todo o cluster.
Nós do Kubernetes
Uma máquina (física ou virtual) precisaria de alguns componentes importantes que, uma vez instalados e configurados corretamente, podem transformar esse servidor em um membro do seu cluster Kubernetes.
A primeira coisa que você precisa é de um tempo de execução de contêiner, como Docker, instalado e em execução nele. Será responsável por girar e gerenciar contêineres, obviamente.
Junto com o tempo de execução do Docker, também precisamos do Kubelet demônio. Ele se comunica com os nós mestres, por meio do servidor da API, consulta o etcd e fornece informações de saúde e uso sobre os pods que estão sendo executados naquele nó.
No entanto, os contêineres são bastante limitados por si próprios, então o Kubernetes tem uma abstração mais alta construída sobre uma coleção de contêineres, conhecida como Pods.
Por que criar vagens?
O Docker tem uma política de execução de um aplicativo por contêiner. Muitas vezes descrito como o “Um processo por contêiner” política. Isso significa que se você precisa de um site WordPress, é recomendável ter dois contêineres, um para o banco de dados e outro para o servidor web. Agrupar esses componentes relacionados de um aplicativo em um pod garante que sempre que você escalar horizontalmente, os dois contêineres interdependentes sempre coexistam no mesmo nó e, assim, se comunicam de forma rápida e fácil.
Os pods são a unidade fundamental de implantação no Kubernetes. Ao fazer o escalonamento horizontal, você adiciona mais pods ao cluster. Cada pod recebe seu próprio endereço IP exclusivo na rede interna do cluster.
De volta ao nó Kubernetes
Agora, um nó pode executar vários pods e pode haver muitos desses nós. Tudo bem até que você pense em tentar se comunicar com o mundo externo. Se você tiver um serviço simples baseado na web, como direcionaria 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 para a Internet. Por exemplo, seu front-end pode ser disponibilizado publicamente e o kube-proxy distribui 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 a comunicação interna para tais cargas de trabalho relacionadas ao back-end.
Você precisa de tudo isso?
Se você está apenas começando como um amador ou um estudante, usar o Kubernetes para um aplicativo simples seria, na verdade, ineficiente. Todo o rigmarole consumiria mais recursos do que sua aplicação 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 adicionar sobrecarga. Você pode impedir que as coisas fiquem caóticas. Abra espaço para manutenção sem qualquer tempo de inatividade. Configure condições de teste A / B bacanas e amplie gradualmente sem gastar muito na infraestrutura inicial.
