Como funcionam as implementações do Kubernetes
O aplicativo de rastreamento de drones tem vários componentes que são implantados separadamente uns dos outros. A sua tarefa é configurar as implementações para estes componentes no cluster. Aqui, você examina algumas das opções de implantação disponíveis para implantar esses componentes.
Opções de implementação de pod
Existem várias opções para gerir a implementação de pods num cluster do Kubernetes ao utilizar o kubectl. As opções são:
- Modelos de pod
- Controladores de replicação
- Conjuntos de réplicas
- Implementações
Você pode usar qualquer uma dessas quatro definições de tipo de objeto do Kubernetes para implantar um pod ou pods. Esses arquivos fazem uso de YAML para descrever o estado pretendido do pod ou pods a serem implantados.
O que é um modelo 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 do contêiner e qual registro de contêiner usar para buscar as imagens. O modelo também inclui informações de configuração de tempo de execução, como portas a serem usadas. Os modelos são definidos quando o YAML é utilizado da mesma forma que quando cria ficheiros do Docker.
Pode utilizar modelos para implementar pods manualmente. No entanto, um pod implementado manualmente não é reiniciado após falhar, ser eliminado ou terminado. Para gerenciar o ciclo de vida de um pod, você precisa criar um objeto Kubernetes de nível superior.
O que é um controlador de replicação?
Um controlador de replicação utiliza modelos de pod e define um número específico de pods que têm de ser executados. O controlador ajuda a executar múltiplas instâncias do mesmo pod e garante que os pods estão sempre a ser executados num ou mais nós no cluster. Um controlador substitui os pods em execução desta forma por novos pods se estes falharem, forem eliminados ou terminados.
Por exemplo, suponha que você implante o site front-end de rastreamento de drones e os usuários comecem a acessar o site. Se todos os pods falharem por algum motivo, o site fica indisponível para os utilizadores, a menos que inicie novos pods. Um controlador de replicação ajuda a garantir que o seu site está sempre disponível.
O que é um conjunto de réplicas?
Um conjunto de réplicas substitui o controlador de replicação como a forma preferida para implementar réplicas. Um conjunto de réplicas inclui a mesma funcionalidade de 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 a serem executados em segundo plano. Com esta funcionalidade, pode gerir os pods que são etiquetados com os mesmos valores que o valor seletor, mas não criados com o conjunto replicado.
O que é uma implementação?
Uma implantação cria um objeto de gerenciamento um nível mais alto do que um conjunto de réplicas e permite implantar e gerenciar atualizações para pods em um cluster.
Imagine que tem cinco instâncias da sua aplicação implementadas no seu cluster. Existem cinco pods a executar a versão 1.0.0 da sua aplicação.
Se você decidir atualizar seu aplicativo manualmente, poderá remover todos os pods e, em seguida, iniciar novos pods executando a versão 2.0.0 do seu aplicativo. Com essa estratégia, seu aplicativo enfrenta tempo de inatividade.
Em vez disso, você deseja executar uma atualização contínua onde você inicia pods com a nova versão do seu aplicativo antes de remover os pods com a versão mais antiga do aplicativo. As atualizações contínuas lançam um pod de cada vez, em vez de derrubar todos os pods mais antigos de uma só vez. As implementações respeitam o número de réplicas configuradas na secção que descreve as informações sobre o conjunto de réplicas. Ele mantém o número de pods especificado no conjunto de réplicas, pois substitui pods antigos por pods novos.
Por predefinição, as implementações fornecem uma estratégia de atualização sem interrupções para atualizar os pods. Também pode utilizar uma estratégia de recriação. Esta estratégia encerra pods antes de lançar novos pods.
As implementações também fornecem uma estratégia de reversão, que pode executar ao utilizar o kubectl.
As implementações utilizam ficheiros de definição baseados em YAML e facilitam a gestão de implementações. Tenha em atenção que as implementações lhe permitem aplicar qualquer alteração ao seu cluster. Por exemplo, pode implementar novas versões de uma aplicação, atualizar etiquetas e executar outras réplicas dos seus pods.
O kubectl tem uma sintaxe conveniente para criar uma implementação automaticamente ao utilizar o comando kubectl run para implementar um pod. Este comando cria uma implementação com o conjunto de réplicas e os pods necessários. No entanto, o comando não cria um ficheiro de definição. É uma prática recomendada 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 sobre implementação
O Kubernetes tem requisitos específicos relativamente ao modo de configurar redes e armazenamento para um cluster. O modo como configura estes dois aspetos afeta as suas decisões acerca de como expor as suas aplicações na rede de cluster e armazenar dados.
Por exemplo, cada um dos serviços no aplicativo de rastreamento de drones tem requisitos específicos para acesso do usuário, acesso à rede entre processos e armazenamento de dados. Agora, vamos dar uma olhada nesses aspetos do cluster do Kubernetes e como eles afetam a implantação de aplicativos.
Redes do Kubernetes
Imagine que tem um cluster com um plano de controlo e dois nós. Ao adicionar nós ao Kubernetes, um endereço IP é automaticamente atribuído a cada nó de um intervalo de rede privada interno. Por exemplo, imagine que o seu intervalo de rede local é 192.168.1.0/24.
Cada pod implementado é atribuído a um IP de um conjunto de endereços IP. Por exemplo, suponha que sua configuração usa o intervalo de rede 10.32.0.0/12, como mostra a imagem a seguir.
Por predefinição, os pods e nós não podem comunicar entre eles com intervalos de endereço IP diferentes.
Para complicar a situação, lembre-se de que os pods são transitórios. O endereço IP do pod é temporário e não pode ser utilizado para restabelecer ligação com um pod criado recentemente. Essa configuração afeta como seu aplicativo se comunica com seus componentes internos e como você e os serviços interagem com ele externamente.
Para simplificar a comunicação, o Kubernetes espera que configure as redes para que:
- Os pods possam comunicar entre si nos diferentes nós sem a Tradução de Endereços de Rede (NAT).
- Os nós podem comunicar com todos os pods e vice-versa, sem NAT.
- Os agentes num nó possam comunicar com todos os nós e pods.
O Kubernetes oferece várias opções de rede que pode instalar para configurar redes. Por exemplo, o Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T e Weave Net.
Os fornecedores de cloud também fornecem as suas próprias soluções de rede. Por exemplo, o Azure Kubernetes Service (AKS) suporta a interface de rede de contentores (CNI) da Rede Virtual do Azure, Kubenet, Flannel, Cilium e Antrea.
Serviços do Kubernetes
Um serviço Kubernetes é um objeto do Kubernetes que fornece redes estáveis para pods. Um serviço Kubernetes permite a comunicação entre nós, pods e usuários do seu aplicativo (internos e externos) para o cluster.
O Kubernetes atribui um endereço IP a um serviço durante a criação, como acontece com um nó ou pod. Esses endereços são atribuídos a partir do intervalo de IP de um cluster de serviços; por exemplo, 10.96.0.0/12. A um serviço é também atribuído um nome DNS com base no nome do serviço e uma porta IP.
No aplicativo de rastreamento de drones, a comunicação de rede é a seguinte:
O site e a API RESTful estão disponíveis para os utilizadores fora do cluster.
Os serviços de cache dentro da memória e fila de mensagens estão acessíveis para os utilizadores de front-end e a API RESTful respetivamente, mas não para os utilizadores externos.
A fila de mensagens precisa de acesso ao serviço de processamento de dados, mas não a usuários externos.
A base de dados NoSQL está acessível para os serviços de cache dentro da memória e processamento de dados, mas não para os utilizadores externos.
Para suportar estes cenários, pode configurar três tipos de serviços para expor os componentes da sua aplicação.
| Serviço | Descrição |
|---|---|
| ClusterIP | O endereço atribuído a um serviço que torna o serviço disponível para um conjunto de serviços dentro de um cluster. Por exemplo, a comunicação entre os componentes de front-end e back-end da sua aplicação. |
| 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, pode configurar o serviço com uma porta de destino no pod que pretende expor. Por exemplo, pode configurar a porta 80 no pod a executar um dos front-ends. Agora, pode aceder ao front-end através de um IP do nó e endereço de porta. |
| LoadBalancer | O balanceador de carga que permite a distribuição da carga entre os nós em execução na sua aplicação e a exposição do pod para o acesso de rede pública. Normalmente, configuramos balanceadores de carga quando utilizamos fornecedores de cloud. Neste caso, o tráfego do balanceador de carga externo é direcionado aos pods em execução na sua aplicação. |
No aplicativo de rastreamento de drone, você pode decidir expor o site de rastreamento e a API RESTful usando um LoadBalancer e o serviço de processamento de dados usando um ClusterIP.
Como agrupar pods
Gerir pods por endereço IP não é prático. Os endereços IP do pod são alterados à medida que os controladores os recriam. Pode ter o número de pods que quiser em execução.
Um objeto de serviço permite-lhe direcionar e gerir pods específicos no seu cluster ao utilizar etiquetas de seletor. Pode definir a etiqueta de seletor numa definição do serviço para corresponder à etiqueta do pod definida no ficheiro de definição do pod.
Por exemplo, imagine que tem muitos pods em execução. Apenas alguns destes pods estão no front-end e quer definir um serviço LoadBalancer direcionado apenas aos pods de front-end. Pode aplicar o seu serviço para expor estes pods ao referenciar a etiqueta do pod como um valor seletor no ficheiro de definição do serviço. O serviço agrupa apenas os pods que correspondem ao rótulo. Se um pod for removido e recriado, o novo pod será automaticamente adicionado ao grupo de serviço através da sua etiqueta correspondente.
Armazenamento do Kubernetes
O Kubernetes utiliza o mesmo conceito de volume de armazenamento que encontra ao utilizar o Docker. Os volumes do Docker são menos gerenciados do que os volumes do Kubernetes, porque os tempos de vida dos volumes do Docker não são gerenciados. A duração do volume do Kubernetes é uma duração explícita que corresponde à duração do pod. Esta correspondência de durações significa que um volume dura mais do que os contentores que são executados no pod. No entanto, se o pod for removido, o volume também é.
O Kubernetes fornece opções para aprovisionar armazenamento persistente ao utilizar a opção PersistentVolumes. Também pode pedir armazenamento específico para pods ao utilizar a opção PersistentVolumeClaims.
Terá de considerar ambas estas opções ao implementar componentes da aplicação que necessitam de armazenamento persistente, como as filas de mensagens e as bases de dados.
Considerações sobre a integração na cloud
O Kubernetes não dita a pilha de tecnologia que utiliza na sua aplicação nativa de cloud. Num ambiente na cloud, como no Azure, pode utilizar vários serviços fora do cluster do Kubernetes.
Lembre-se de que o Kubernetes não fornece qualquer dos seguintes serviços:
- Middleware
- Estruturas de processamento de dados
- Bases de Dados
- Caches
- Sistemas de armazenamento de clusters
Nesta solução de rastreamento de drones, há três serviços que fornecem funcionalidade de middleware: um banco de dados NoSQL, um serviço de cache na memória e uma fila de mensagens. Você pode selecionar MongoDB Atlas para a solução NoSQL, Redis para gerenciar cache na memória e, RabbitMQ ou Kafka, dependendo de suas necessidades de fila de mensagens.
Ao utilizar um ambiente na cloud como o Azure, a melhor prática é utilizar os serviços fora do cluster do Kubernetes. Esta decisão pode simplificar a configuração e gestão do cluster. Por exemplo, pode utilizar a Cache do Azure para Redis para os serviços de colocação em cache, as mensagens do Azure Service Bus para a fila de mensagens e o Azure Cosmos DB para a base de dados NoSQL.