Como funcionam as implantações do Kubernetes
O aplicativo de acompanhamento de drones traz vários componentes que são implantados separadamente um do outro. Cabe a você configurar implantações para esses componentes no cluster. Aqui, você analisará algumas das opções de implantação disponíveis para implantar esses componentes.
Opções de implantação de pod
Há várias opções para gerenciar a implantação de pods em um cluster do Kubernetes ao usar o kubectl. As opções são:
- Modelos de pod
- Controladores de replicação
- Conjuntos de réplicas
- Implantações
Você pode usar uma dessas quatro definições de tipo de objeto do Kubernetes para implantar um ou mais pods. Esses arquivos fazem uso do YAML para descrever o estado pretendido dos pods a serem implantados.
O que é um modelo de pod?
Um modelo de pod permite que você defina a configuração do pod que deseja implantar. O modelo contém informações como o nome da imagem de contêiner e o registro de contêiner a ser usado para buscar as imagens. O modelo também inclui informações de configuração de runtime, como as portas a serem usadas. Os modelos são definidos por meio do YAML, da mesma forma como quando você cria arquivos do Docker.
Você pode usar modelos para implantar os pods manualmente. No entanto, um pod implantado manualmente não é reiniciado depois que ele falha, é excluído ou encerrado. Para gerenciar o ciclo de vida de um pod, você precisa criar um objeto de nível superior do Kubernetes.
O que é um controlador de replicação?
Um controlador de replicação usa modelos de pod e define um número especificado de pods que precisa ser executado. O controlador ajuda você a executar várias instâncias do mesmo pod e verifica se os pods estão sempre em execução em um ou mais nós do cluster. Ele substitui os pods em execução dessa forma por novos pods caso eles falhem, sejam excluídos ou encerrados.
Por exemplo, suponha que você implante o site front-end de acompanhamento de drones e os usuários comecem a acessá-lo. Se todos os pods falharem por algum motivo, o site não ficará disponível aos usuários, a menos que você inicie novos pods. Um controlador de replicação ajuda você a garantir que o seu site fique sempre disponível.
O que é um conjunto de réplicas?
Um conjunto de réplicas substitui o controlador de replicação como a maneira preferencial de implantar réplicas. Um conjunto de réplica inclui a mesma funcionalidade que um controlador de replicação, mas tem uma opção de configuração extra para incluir um valor de seletor.
Um seletor permite que o conjunto de réplicas identifique todos os pods em execução abaixo dele. Usando esse recurso, você pode gerenciar os pods rotulados com o mesmo valor que o seletor, mas não criados com o conjunto replicado.
O que é uma implantação?
Uma implantação cria um objeto de gerenciamento um nível acima de um conjunto de réplicas e permite que você implante e gerencie as atualizações dos pods de um cluster.
Suponha que você tenha cinco instâncias do aplicativo implantadas no seu cluster. Há cinco pods executando a versão 1.0.0 do aplicativo.
Se você decidir atualizar o aplicativo manualmente, poderá remover todos os pods e iniciar novos pods executando a versão 2.0.0 do aplicativo. Com essa estratégia, seu aplicativo enfrenta um tempo de inatividade.
Em vez disso, o ideal é executar uma atualização sem interrupção, na qual você inicia os pods com a nova versão do aplicativo antes de remover os pods mais antigos do aplicativo com controle de versão. As atualizações sem interrupção iniciam um pod de cada vez, em vez de desativar todos os pods mais antigos ao mesmo tempo. As implantações respeitam o número de réplicas configuradas na seção que descreve informações sobre os conjuntos de réplicas. Elas mantêm o número de pods especificado no conjunto de réplicas à medida que substituem os pods antigos pelos novos.
Por padrão, as implantações fornecem uma estratégia de atualização sem interrupção para atualizar os pods. Você também pode usar uma estratégia de recriação. Essa estratégia encerra os pods antigos antes de iniciar os novos.
As implantações também fornecem uma estratégia de reversão, que pode ser executada usando kubectl.
As implantações fazem uso de arquivos de definição baseados em YAML e facilitam o gerenciamento das implantações. Tenha em mente que as implantações permitem que você aplique todas as alterações ao cluster. Por exemplo, você pode implantar novas versões de um aplicativo, atualizar rótulos e executar outras réplicas dos pods.
kubectl tem uma sintaxe conveniente para criar uma implantação automaticamente ao usar o comando kubectl run para implantar um pod. Este comando cria uma implantação com o conjunto de réplicas e os pods necessários. No entanto, o comando não cria um arquivo de definição. Uma melhor prática é gerenciar todas as implantações com arquivos de definição de implantação e controlar as alterações usando um sistema de controle de versão.
Considerações de implantação
O Kubernetes tem requisitos específicos sobre como configurar a rede e o armazenamento de um cluster. A maneira como você configura esses dois aspectos afeta suas decisões sobre como expor seus aplicativos na rede de cluster e armazenar os dados.
Por exemplo, cada um dos serviços do aplicativo de acompanhamento de drones tem requisitos específicos para acesso à rede por usuário e entre processos, bem como para o armazenamento de dados. Agora, examine esses aspectos de um cluster do Kubernetes e como eles afetam a implantação de aplicativos.
Rede do Kubernetes
Suponha que você tenha um cluster com um painel de controle e dois nós. Quando você adiciona nós ao Kubernetes, um endereço IP é atribuído automaticamente a cada nó de um intervalo de rede privada interna. Por exemplo, suponha que o intervalo da sua rede local seja 192.168.1.0/24.
A cada pod que você implanta é atribuído um IP de um pool de endereços IP. Por exemplo, suponha que a sua configuração use o intervalo de rede 10.32.0.0/12, conforme mostrado na imagem a seguir.
Por padrão, os pods e os nós não podem se comunicar entre si usando intervalos de endereços IP diferentes.
Para complicar ainda mais as coisas, lembre-se de que os pods são transitórios. O endereço IP do pod é temporário e não pode ser usado para se reconectar a um pod recém-criado. Essa configuração influencia a maneira como seu aplicativo se comunica com os componentes interno, assim como a interação entre você e os serviços internos.
Para simplificar a comunicação, o Kubernetes espera que você configure a rede de tal forma que:
- Os pods possam se comunicar entre si de diferentes nós, sem a NAT (Conversão de Endereços de Rede).
- Os nós podem se comunicar com todos os pods sem a NAT, e vice-versa.
- Os agentes de um nó possam se comunicar com todos os nós e os pods.
O Kubernetes oferece várias opções de rede que você pode instalar para configurar a rede. Por exemplo, Antrea, Cisco ACI (Application Centric Infrastructure), Cilium, Flannel, Kubenet, VMware NSX-T e Weave Net.
Os provedores de nuvem também fornecem soluções de rede próprias. Por exemplo, o AKS (Serviço de Kubernetes do Azure) é compatível com a CNI (Adaptador de Rede de Contêiner) da Rede Virtual do Azure, Kubenet, Flannel, Cilium e Antrea.
Serviços de Kubernetes
Um serviço de Kubernetes é um objeto do Kubernetes que fornece uma rede estável para os pods. O serviço de Kubernetes permite a comunicação entre nós, pods e usuários do aplicativo (tanto internos quanto externos) e o cluster.
O Kubernetes atribui um endereço IP ao serviço na criação, assim como um nó ou um pod. Esses endereços são atribuídos a partir do intervalo de IP do cluster de serviço; por exemplo: 10.96.0.0/12. Também é atribuído ao serviço um nome DNS com base no nome do serviço e em uma porta IP.
No aplicativo de acompanhamento de drones, a comunicação de rede é a seguinte:
O site e a API RESTful podem ser acessados por usuários fora do cluster.
Os serviços de cache na memória e de fila de mensagens podem ser acessados pelo front-end e pela API RESTFul, respectivamente, mas não por usuários externos.
A fila de mensagens precisa de acesso ao serviço de processamento de dados, mas não a usuários externos.
O banco de dados NoSQL pode ser acessado pelo serviço de cache na memória e de processamento de dados, mas não por usuários externos.
Para dar suporte a esses cenários, você pode configurar três tipos de serviços para expor os componentes do aplicativo.
| Serviço | Descrição |
|---|---|
| ClusterIP | O endereço atribuído a um serviço que disponibiliza o serviço para um conjunto de serviços dentro do cluster. Por exemplo, a comunicação entre os componentes de front-end e back-end do aplicativo. |
| NodePort | A porta do nó entre 30000 e 32767 que o plano de controle do Kubernetes atribui ao serviço; por exemplo, 192.169.1.11 em clusters01. Em seguida, você vai configurar o serviço com uma porta de destino no pod que você deseja expor. Por exemplo, configure a porta 80 no pod que executa um dos front-ends. Agora você pode acessar o front-end por meio de um IP de nó e um endereço de porta. |
| LoadBalancer | O balanceador de carga que permite a distribuição de carga entre os nós que executam o aplicativo e que expõem o pod ao acesso à rede pública. Normalmente, você configura balanceadores de carga ao usar provedores de nuvem. Nesse caso, o tráfego do balanceador de carga externo é direcionado ao pods que executam o aplicativo. |
No aplicativo de acompanhamento de drones, você pode optar por expor o site de acompanhamento e a API RESTful usando um LoadBalancer e o serviço de processamento de dados usando um ClusterIP.
Como agrupar os pods
O gerenciamento de pods pelo endereço IP não é prático. Os endereços IP dos pods mudam conforme os controladores os recriam, e pode haver qualquer número de pods em execução.
Um objeto de serviço permite que você tenha como alvo e gerencie pods específicos em seu cluster usando rótulos de seletor. Você define o rótulo do seletor em uma definição de serviço para corresponder ao rótulo de pod definido no arquivo de definição do pod.
Por exemplo, suponha que você tenha muitos pods em execução. Apenas alguns desses pods estão no front-end e você deseja definir um serviço LoadBalancer que tenha como alvo apenas os pods de front-end. Você pode aplicar seu serviço para expor esses pods referenciando o rótulo de pod como o valor de seletor configurado no arquivo de definição do serviço. Agora, o serviço agrupa apenas os pods que correspondem ao rótulo. Se um pod for removido e recriado, o novo pod será adicionado automaticamente ao grupo de serviços por meio do rótulo correspondente.
Armazenamento do Kubernetes
O Kubernetes usa o mesmo conceito de volume de armazenamento que você encontra ao usar o Docker. Os volumes do Docker são menos gerenciados do que os do Kubernetes, pois os tempos de vida do volume do Docker não são gerenciados. O tempo de vida do volume do Kubernetes é um tempo de vida explícito que corresponde ao tempo de vida do pod. Essa correspondência de tempo de vida significa que o volume vive mais que os contêineres que são executados no pod. No entanto, se o Pod é removido, o volume também é removido.
O Kubernetes fornece opções para provisionar o armazenamento persistente com o uso de PersistentVolumes. Você também pode solicitar armazenamento específico para pods usando PersistentVolumeClaims.
Tenha essas duas opções em mente ao implantar componentes de aplicativos que exijam um armazenamento persistente, como filas de mensagens e bancos de dados.
Considerações sobre a integração com a nuvem
O Kubernetes não impõe a pilha de tecnologia que você usará no aplicativo nativo de nuvem. Em um ambiente de nuvem, como o Azure, você pode usar vários serviços fora do cluster do Kubernetes.
Lembre-se de que o Kubernetes não fornece nenhum dos seguintes serviços:
- Middleware
- Estruturas de processamento de dados
- Bancos de dados
- Caches
- Sistemas de armazenamento de cluster
Na solução de acompanhamento de drones, há três serviços que fornecem a funcionalidade de middleware: um banco de dados NoSQL, um serviço de cache em memória e uma fila de mensagens. Você pode escolher o Atlas do MongoDB como a solução NoSQL, o Redis para gerenciar o cache em memória e o RabbitMQ ou o Kafka, dependendo das suas necessidades de fila de mensagens.
Ao usar um ambiente de nuvem como o Azure, é uma melhor prática usar serviços fora do cluster do Kubernetes. Essa decisão pode simplificar a configuração e o gerenciamento do cluster. Por exemplo, você pode usar o Cache do Azure para Redis para os serviços de cache em memória, o sistema de mensagens do Barramento de Serviço do Azure para a fila de mensagens e o Azure Cosmos DB para o banco de dados NoSQL.