Achei interessante que enquanto acompanhava com a aula esqueci de deletar o pod antigo do portal-noticias e quando subi o replica set percebi que o pod que eu não tinha deletado estava sendo usado como um node do replica set. Deletei o pod e logo depoys o kubernetes subiu um novo, seguindo o padrão dos outros 2
hoje, com a Alura e o Google Gemini
Olá, Caio.
Tudo bem?
Interessante observar o comportamento que você descreveu com o ReplicaSet no Kubernetes. O que aconteceu no seu caso é um comportamento esperado, dado que os ReplicaSets garantem que um número específico de réplicas de um pod estejam sempre em execução. Quando você não deletou o pod antigo e subiu o ReplicaSet, o Kubernetes verificou que já existia um pod que atendia às especificações do ReplicaSet e, por isso, inicialmente não precisou criar um novo.
Quando você deletou o pod, o ReplicaSet identificou que o número de pods ativos era menor que o desejado e criou um novo pod para manter o estado desejado. Isso demonstra a capacidade de auto-cura do Kubernetes, que é uma das grandes vantagens de usar ReplicaSets.
A imagem que você compartilhou mostra claramente esse processo. No terminal, podemos ver que após a aplicação do arquivo portal-noticias-replicaset.yaml, o ReplicaSet foi criado e os pods foram gerenciados conforme especificado. Quando o pod pod-portal-noticias foi deletado, o ReplicaSet rapidamente reagiu criando um novo pod para substituir o que foi perdido, mantendo assim a consistência e disponibilidade da aplicação.
Esse é um exemplo prático de como os ReplicaSets ajudam a gerenciar os pods de forma eficiente, garantindo que a aplicação permaneça estável e disponível mesmo frente a falhas de pods individuais.
Espero ter ajudado. Qualquer dúvida manda aqui. Bons estudos.