Bom pessoal, então para recapitular o que a gente acabou falando sobre replica sets, é basicamente isso que acontece. Eu tenho os meus containers que podem estar dentro de um pod, e o replica set fica fazendo o que? Ele fica verificando se eu tenho a quantidade desejada de pods aqui dentro. Se eu apagar um novo pod e criar novamente, ele vai criar baseado na imagem que foi solicitada para ele naquele momento. Normalmente, o réplica 7 tem a limitação de que, se você troca a imagem ali do nosso container, ele não vai apagar os outros containers ou substituir ou fazer uma troca de imagem. Porque o objetivo dele é somente garantir que eu tenho aqueles pods rodando. Legal? Mas, como eu disse para vocês, não tem para onde fugir. Se você quer trocar a versão do seu container, da sua aplicação, que é o que acontece toda hora, não tem para onde fugir. Você tem que apagar os pods antigos e subir pods novos. O ponto é fazer isso de forma manual e isso é inviável. E é por isso que nós temos um outro camarada no Kubernetes que envolve o replica set. Esse cara aqui é chamado de deployment. Os deployments. Como é que ele funciona? O deployment exerce o controle sobre os replica sets. Ou seja, da mesma forma que eu tenho um pod e por fora do pod eu tenho um replica set, o deployment fica de uma visão mais macro ainda,ria um novo replica set. E esse replica set, o que acontece com ele? Ele começa a criar novos pods. Porém, enquanto ele cria uma nova versão desse replica set, o deployment também pede para o replica set antigo falar que o estado desejado dele de réplicas seja igual a zero. Então, o que vai acontecer? Ele vai começar a apagar as réplicas antigas e vai começar a criar réplicas novas baseado no novo réplica 7. Legal? E o que acontece é o seguinte. Caso a versão anterior seja aplicada novamente, vou imaginar que eu estou rodando a aplicação com a versão A, daí eu mudei para a versão B. Aí quando eu volto para a versão A novamente, o que o deployment faz? Ele vê que já existiu no passado um replica set com aquela versão. Então o que ele deployment faz? Ele vê que já existiu no passado um replica 7 com aquela versão, então o que ele vai fazer? Ele vai mandar subir os pods naquele replica 7 antigo e, obviamente, vai zerar a quantidade de pods no replica 7 que está atual. Então, no final das contas,as galera o que acontece é que o deployment ele exerce controle sobre o réplica 7 eles fala para o réplica 7 quando réplica 7 deve fazer alteração na quantidade de réplicas tanto para mais quanto para menos e quando ele fala para mudar para zero réplicas é porque provavelmente o deployment vai criar um novo replica 7 para subir versões novas da nossa aplicação então olhando aqui para o nosso gráfico fica algo mais ou menos dessa forma tá então essa borda amarela é o nosso deployment tá o deployment ele controla as nossas réplicas, que nesse caso são 10 réplicas. E o replica set, que gerencia essas 10 réplicas, são as responsáveis por fazer a criação dos nossos pods. Nesse caso, nós temos dois containers dentro de um pod. Se em algum momento a versão da imagem que a gente for trabalhar mudar, o nosso deployment, que é a camada amarela, vai criar um novo replica set. Esse replica set vai começar a subir novos pods e o replica 7 antigo vai começar a matar os pods antigos para que você fique apenas com a versão nova em funcionamento. É basicamente assim que funciona quando você está trabalhando com Kubernetes. Pode parecer um pouco complexo no começo, e de fato é, mas quando você entende a ideia por trás, fica muito mais simples. Eu prefiro explicar dessa forma do que sair só criando o código e você vendo, e você não entende o que está acontecendo por trás do Kubernetes. Então é essa a ideia. E para que a gente consiga ver tudo isso na prática, o que eu vou fazer? Sim, eu vou criar alguns deployments para a gente brincar. Vamos nessa.