Otimize a infraestrutura de TI da sua empresa com soluções Kubernetes. Garanta a alta disponibilidade, robustez e eficiência dos seus sistemas, assegurando operações ininterruptas e maximizando a produtividade. Descubra como o Kubernetes pode ser a chave para a excelência operacional da sua empresa
Você Vai Gostar Também de:
Cluster sem Alta Disponibilidade
Então, o que acontece quando ocorre a perda do nó master em um cluster? Enquanto os workers estiverem em operação e os containers estiverem ativos, as aplicações ainda permanecerão funcionando.
Os usuários poderão acessar as aplicações até que ocorram falhas. Por exemplo, se um container ou uma pod no nó worker falhar. Caso a pod faça parte de um conjunto de réplicas, o controlador de replicação no nó master precisará instruir o worker a iniciar um novo pod. No entanto, se o nó master estiver inacessível e os controladores e programadores também estiverem nele, não será possível recriar o pod nem programá-la em outros nós.
Além disso, com o kube-apiserver inacessível, não será possível conectar-se externamente ao cluster por meio da ferramenta kubectl ou utilizar a API para fins de gerenciamento. Por esse motivo, é crucial considerar a configuração de múltiplos nós masters em um ambiente de produção, visando alta disponibilidade.
A configuração de alta disponibilidade envolve a implementação de redundância em todos os componentes do cluster, a fim de evitar um único ponto de falha. Os nós masters, os nós workers e os componentes do plano de controle, assim como as aplicações, já possuem múltiplas réplicas de pods e serviços.
Balanceamento de Carga para Distribuição do Tráfego
Com dois ou mais masters, é necessário direcionar a ferramenta kubectl para um balanceador de carga. Pode-se utilizar o Nginx, HAProxy ou qualquer outro balanceador de carga para essa finalidade. O objetivo é distribuir o tráfego entre os servidores API, evitando enviar a mesma solicitação para ambos os masters.
Scheduler e Controller Manager
O scheduler (programador) e o controller manager (gerente do controlador) são controladores responsáveis por monitorar o estado do cluster e executar ações.
Por exemplo, o controller manager inclui controladores como o controlador de replicação, que monitora constantemente o estado das pods e toma as medidas necessárias, como criar um novo pod em caso de falha, entre outras. Executar várias instâncias desses controladores simultaneamente pode levar à duplicação de ações, resultando em um número maior de pods do que o necessário.
O mesmo princípio se aplica ao scheduler. Portanto, é recomendado evitar a execução simultânea desses controladores. Eles operam em um modo de espera ativa, onde apenas um está ativo em determinado momento. A determinação de qual controlador está ativo e qual está em espera é feita por meio de um processo de eleição de líderes. Tomemos como exemplo o controller manager, onde é possível configurar a opção de eleição de líder, definida como true por padrão.
Etcd – Topologias e Configuração
O etcd é abordado no início deste curso e é importante revisá-lo antes de explorarmos mais detalhes sobre sua funcionalidade. Existem duas topologias possíveis para configurar o etcd no Kubernetes.
Topologia de Nós de Plano de Controle do Cluster
Uma das topologias é a de nós de plano de controle do cluster, que segue a mesma arquitetura apresentada ao longo deste curso, onde o etcd faz parte dos nós masters do Kubernetes. Essa topologia é mais fácil de instalar, gerenciar e requer menos nós. No entanto, se um nó cair, tanto o membro do etcd quanto as instâncias do plano de controle serão perdidos, comprometendo a redundância.
Topologia com Servidores Etcd Externos
A outra topologia envolve a separação do etcd dos nós de plano de controle, executando-o em um conjunto de servidores dedicados. Essa é uma topologia com servidores etcd externos. Comparada à topologia anterior, é menos arriscada, pois uma falha em um nó de plano de controle não afeta o cluster etcd e os dados armazenados nele. No entanto, essa topologia é mais complexa de configurar e requer o dobro do número de servidores para os nós etcd externos.
Independentemente da topologia escolhida e da localização dos servidores etcd, seja no mesmo servidor ou em um servidor separado, é fundamental garantir que o servidor etcd esteja devidamente configurado e acessível para o bom funcionamento do cluster.
Conclusão
Em suma, a robustez e a resiliência de um cluster Kubernetes dependem fortemente da configuração e da arquitetura adotadas. A perda do nó master pode ter implicações significativas para a continuidade das operações, destacando a importância de considerar estratégias de alta disponibilidade e redundância. Além disso, a escolha da topologia, seja integrando o etcd aos nós de plano de controle ou mantendo-o em servidores dedicados, desempenha um papel crucial na determinação da estabilidade e eficiência do sistema. Portanto, ao projetar e implementar soluções baseadas em Kubernetes, é essencial ponderar cuidadosamente todas essas considerações para garantir um ambiente de produção confiável e otimizado.
