Bom pessoal, no nosso vídeo anterior nós falamos sobre os réplicas sets e a importância deles em relação ao Kubernetes para garantir a quantidade de pods rodando. Legal? Mas, porém, contudo, todavia, eu quero mostrar um experimento que nós vamos fazer agora com o réplica set e eu quero ver se você se liga do que eu estou querendo fazer tá que eu vou fazer vai ser o seguinte eu vou falar que eu quero apenas uma réplica então eu vou dar uma playa aqui vamos lá e você vai ver agora que no réplica 7 que eu desejo apenas uma réplica aqui pra mim então se, se eu der um kubectl get pods, ele foi lá e apagou os outros pods aqui para mim, e eu tenho apenas um. Agora, olha só que interessante. Vamos imaginar que a gente gerou uma versão 2 da nossa aplicação, e a gente teve que fazer o deploy dessa aplicação, tá? Vamos imaginar que aqui a gente mudou o container não é mais o engine x o clark colocar aqui sei lá o quer por exemplo tá e eu vou rodar aqui uma play réplica 7 agora a minha pergunta que não quer calar aqui pra aqui para você quando eu rodar esse pod vai estar rodando quem? o Nginx ou o CAD? essa é a pergunta aqui que não vai que é uma pergunta de milhão de dólares vamos dizer aqui porque uma coisa galera é eu manter o estado do meu cluster funcionando com as aplicações que eu tenho funcionando, mas a cada momento eu tenho que fazer um deploy que vai mudar a versão da minha aplicação, e isso é super comum, tá? Então, quando eu tenho o meu replica set e eu mudo a versão, eu mudo o meu container que vai rodar, o que acontece? Vamos lá. Eu vou dar um kubectl get pods. Está rodando aqui ainda esse meu pod. O que eu vou fazer? Eu vou fazer aquela parada assim. kubectl port forward port forward pod barra o nome do meu pod 8000 2.80 vou colocar aqui para a gente rodar atualizei e ainda eu estou rodando com o Nginx vamos fazer o seguinte agora? Eu vou com o kubectl, get pods, vou apagar esse meu pod e ele vai ser criado automaticamente de novo. Kubectl, delete pod, apaguei esse pod. Se eu der um get pods agora aqui, ele já criou um outro aqui, porque o meu replica 7 é bem esperto. Então agora eu vou dar um kubectl port forward pod barra o nome do meu pod, 8000, 2.80. Está rodando. Vou atualizar. 580, está rodando, vou atualizar, e aqui estou rodando um outro web server. Agora, a pergunta aqui que não quer calar é a seguinte, galera. Por que eu tive que apagar o meu pod para daí o replica 7 criar o outro com a nova versão. Vamos lá. Pessoal, o negócio é o seguinte. Toda vez que você tem um Replica 7, o objetivo do Replica 7 é manter a quantidade de pods desejada no ar. Se você trocou a imagem do seu container, somente quando ele criar um novo pod, que isso vai ser refletido. Isso significa que os pods atuais não vão ser modificados. E aí a gente entra num ponto que é um deal breaker. Como que eu conseguiria resolver esse problema se eu tivesse 10 pods rodando e eu tivesse que trocar de versão esses 10 pods? A resposta para isso é simples, tá? É uma resposta simples e direta. Você teria que apagar os 10 pods e deixar o seu réplica 7 criar novamente esses 10 pods. Não tem para onde escapar. Se você quer mudar a versão do pod, você tem que matar o pod para que o novo seja criado. Ponto e acabou. 100 pods. Como que eu apago tudo isso na mão para eu recriar tudo isso na mão? Como que eu apago todos esses caras e evito um downtime? Como que eu consigo fazer um rollout progressivo para que ele apague um e crie outro? Apague um e crie outro para evitar que eu fique com downtime e para garantir a estabilidade da minha aplicação. Perceba que esse é um outro desafio, entende? Porque o Replica 7, ele só garante os pods funcionando. Se você quiser um novo, uma nova versão, você apaga esse pod aí para a gente, legal? Então isso aí é um ponto importantíssimo para você e a gente vai ver isso no nosso próximo vídeo.