Kubernetes Rolling Update | Como atualizar a sua aplicação no Kubernetes

um ponto fundamental hoje quando a gente quer entregar soluções escaláveis e de grande porte é pensar na atualização das nossas aplicações não dá mais para você deixar o sistema indisponível pensar em janela de Deploy para atualizar o seu sistema o usuário ele tá utilizando o sistema o tempo todo então você precisa ser capaz de trocar o pneu do carro com ele andando você tem que garantir aplicações escaláveis resilientes rodando 24x 7 e para fazer isso você precisa entender a maneira correta de fazer a atualização da sua aplicação utilizando o kubernetes e esse é o objetivo

do vídeo de [Aplausos] [Música] hoje Fala aí beleza seja bem-vindo seja bem-vinda a mais esse vídeo aqui no canal Hoje a gente vai falar sobre como atualizar as nossas aplicações da forma correta no kubernetes porque muitas vezes a gente deixa o kubernetes fazer aí no piloto automático Mas tem como a gente refinar esse comportamento para trazer muito mais eficiência na hora de consumir recursos do kubernet velocidade de atualização e garantir um downtime zero uma experiência muito melhor pro seu cliente Principalmente quando a gente fala em aplicações 24 por7 e isso vai fazer com que você

se diferencie no mercado sendo capaz de entregar aplicações de Alto desempenho de grande porte de alto disponibilidade se tornando aquele profissional de Elite na área da ti que você quer ser e se você não me conhece eu sou Fabrício Veronez eu tô aqui para ajudar você a criar soluções escaláveis de grande PTE utilizando Cloud E devops então se você quer saber mais sobre esse assunto se inscreve aqui no canal aciona o Sininho para você não perder mais nenhum conteúdo e não deixa também de dar um like no vídeo pro YouTube entender que esse conteúdo é

de qualidade vale a pena ser distribuído e se você quiser saber mais sobre como entregar aplicações escaláveis gigan de porte definindo essas soluções com as principais ferramentas do mercado tudo isso com o meu acompanhamento aqui embaixo vai ter um link para você preencher e eu vou entrar em contato com você para falar sobre a formação devops pro o meu treinamento que vai te ajudar a se tornar um profissional de Elite na área da ti conhecendo sobre Cloud E devops então clica aí a gente vai entrar em contato com você entender o seu momento e saber

como posso te ajudar por padrão o kubernetes ele já tem ali um comportamento que ajuda a gente a atualizar as nossas aplicações quando a gente quer mudar ali de uma versão para outra ele também dá ali mecanismos de rollback caso tenha algum problema você com um comando consegue voltar aí à versão mas muitas vezes eu tenho que ajustar esse comportamento porque eu preciso otimizar em relação a consumo de recurso para ter um controle ali De quanto de recurso computacional Extra o kubernetes ele vai consumir ou até que ele não tenha esse consumo Extra velocidade porque

muitas vezes eu tenho que ter uma janela muito curta de atualização ou maior para poder verificar ali se tá tudo funcionando ter mais tempo ali para verificar o comportamento e trazer também uma experiência melhor pro meu usuário mas como é que funciona o gerenciamento de aplicações no kubernetes vamos revisar aqui um pouquinho eu tenho né o meu principal elemento aqui para fazer o Deploy da minha aplicação que é o deployment esse cara ele vai gerenciar ali a execução dos meus Pods no cluster kubernetes por debaixo dos panos o que que ele tem ele tem o

RCA 7 né que é o controlador que vai cuidar da escalabilidade e resiliência dos meus SPS eu vou ter aqui o réplica 7 certo e abaixo do réplica 7 Deixa eu botar aí mais para cá né abaixo do RCA 7 eu tenho quem eu tenho o pod que vai ser o menor objeto ali do cluster kubernetes né e o RCA 7 ele vai cuidar da quantidade de réplicas e garantir ali a escalabilidade caso eu precise então eu tenho aqui esses três elementos chaves né que formam aqui um Deploy eficiente no kubernet se você não sabe

como funciona um Deploy os elementos de Deploy no kubernet eu vou deixar um vídeo aí embaixo onde eu explico melhor todos esses elementos mas quando eu vou fazer a atualização da minha versão quando eu vou trocar a versão da minha aplicação sair aqui de uma versão sei lá Blue para uma versão Green né para uma versão nova da minha aplicação que é inclusive o exemplo que eu vou usar aqui eh mais pra frente eu o deployment ele vai criar aqui um novo replica set né ele vai criar aqui um um novo objeto RCA 7 e

todos os Pods que vão estar aqui no meu RCA set antigo eles vão ser eliminados e novos vão ser criados aqui no meu RCA set atual Isso é o que o kubernetes ele faz por padrão isso aqui ele já faz pra gente Mas tem como eu controlar aqui a quantidade de Pods que ele vai eliminar né por vez para poder criar os novos ou até quantos ele vai criar aqui antes de eliminar os antigos essa estratégia de troca de versão que é o que nós chamamos aqui de Rolling update no kubernetes Então agora eu quero

mostrar para você como fazer isso aqui no kubernetes certo então eu vou vir aqui pro meu meu terminal certo e eu tenho aqui um cluster kubernetes já criado então se eu vir aqui ó e executar Cub stl get nodes eu tenho aqui um cluster kubernetes esse cluster kubernetes está rodando local tô utilizando aqui o k3d Mas você pode utilizar qualquer cluster kubernetes tá você pode utilizar o kind você pode utilizar o k3d você pode utilizar no Edge na WS um premise não tem problema o que importa é você ter um cluster kubernet e se você

quiser saber como trabalhar com kind da maneira correta criando cluster kubernetes local na sua máquina aqui embaixo na descrição do vídeo tem um guia completo para você trabalhar com o kind que eu fiz há um tempo atrás se você não sabe como fazer clica aqui embaixo confere que tá iradíssimo certo então beleza ten aqui o meu cluster kubernetes agora eu vou abrir aqui o meu vs code certo e aqui eu tenho o Deploy de uma aplicação essa aplicação é uma aplicação web com um fundo aqui azul né por isso o Blue Green né pra gente

ver aqui é tanto ele com fundo azul com o fundo verde e a gente vai brincar aqui de fazer essa troca de versão fazer essa troca do azul pro verde e a gente vê aqui como vai ficar o comportamento eu vou fazer o Deploy aqui a princípio com 10 réplicas e botar esse cara para rodar então vamos lá eu vou vir aqui Cub CTL apply Men F Deploy pemo criei aqui vamos executar aqui Cub CTL get pod ele tá criando aqui os meus Pods Se eu vir aqui Cub CTL get All aqui eu vou ter

tudo né e ainda está criando Mas beleza Ele demora um pouquinho tá baixando a imagem e tudo mais mas agora quando ele terminar aqui de fazer esse Deploy se eu vir aqui local host 30.000 Ah já até tá funcionando deixa eu até conferir aqui ó já tá funcionando ele vai ter aqui essa página de teste onde ele vai mostrar aqui a a Instância que processou essa requisição no caso ali o Pods então se eu vir aqui de novo cubs get All tá aqui ó tudo rodando Tranquilão certo e agora o que que a gente vai

fazer a gente vai fazer a troca de versão né da aplicação a gente vai pegar aqui executar um apply agora com o com a imagem nova que vai ser aqui no caso o Guen e ver o que que ele vai fazer aqui aqui por padrão sem fazer nada se a gente fazer nada aqui vamos ver o que que vai rolar eu vou vir aqui e vou dar um C vou executar aqui Cub CTL apply Men F deployment pemo executo aqui né Se eu vir aqui dá um get All aqui ó ele já tá no processo

de atualização aqui da minha aplicação né então ele já faz aqui meio que o comportamento por padrão né se eu aplicar aqui aí já foi e E trocou a versão mas como é que é esse comportamento do kubernetes o que que ele tá fazendo aqui se a gente vir aqui no no kubernetes e executar o Cub CTL e describe deployment web que é o nome aqui do meu deployment né é o nome aqui do meu do meu objeto de Deploy executo aqui eu vou ter todas as descrições no meu Deploy e aqui ó eu tenho

ó um strategy Type né um tipo de estratégia e aqui tá o Rolling update e aqui eu tenho Rolling update strategy onde ele diz aqui ó 25% Max unavailable e 25% Max surge o que que acontece aqui o que que é essa definição por padrão que é essa configuração no deployment o que que ele vai fazer toda vez que eu for mudar aqui da versão de uma versão antiga para uma nova ele vai utilizar a estratégia de Rolling update onde eu vou progressivamente trocando ali os meus Pods e a regra de troca é a seguinte

ele pode eh matar né E pode diminuir ali o número de Pods atuais em até 25% então vamos supor aqui eu tenho aqui né Eh quatro podes né eu tenho aqui quatro Pods Opa Deixa eu fazer aqui melhor mas eu tenho aqui ó quatro Pods dentro dentro desse Deploy aqui que eu tô rodando aqui nesse momento né tem aqui quatro Pods e quando eu vou fazer essa estratégia de atualização que que ele vai fazer aqui ele vai Opa vai certo que dá certo né que que ele vai fazer aqui ele vai e remover 25% para

poder atualizar aqui então ele vai remover aqui um pod né 25% aqui no caso representa o o número um aqui um pod E aí ele vai matar esse pod para poder criar um novo aqui no RC 7 novo e também né quando eu utilizo o maxge e o Max unavailable né representa isso aqui é o Max unavailable é a quantidade de Pods que eu posso deixar indem disponíveis nesse momento os antigos e o Max surge é quantos que eu posso colocar a mais né então em relação à quantidade atual eu posso trabalhar com um pod

a mais 25% é igual a um pod aqui nesse cenário então aqui ele vai matar um atual e vai criar aqui um a mais certo eu poderia por exemplo colocar aqui que eu só quero trabalhar com 0% aqui de maxge ou seja aí não vai adicionar nenhuma mais e aí com isso eu não tenho recurso computacional a mais sendo utilizado porque eu não tô criando po extra e trabalhar só com o unviable a o problema desse dessa abordagem quando eu trabalho só com o unviable é que eu vou ter ali um problema em relação à

quantidade de requisições que eu posso receber nesse momento já que eu tô diminuindo a quantidade de réplicas prontas para poder processar as minhas requisições então é importante tomar cuidado com isso se você tiver num num momento de alta autoconsumo da sua aplicação Você pode ter problemas de performance né mas você não vai ter nenhum recurso computacional sendo utilizado e eu posso também trabalhar aqui com o Max e unavailable e Zerado sem nada e ele trabalhar só com o Max surge mas aí eu vou ter que trabalhar com recurso computacional Extra né porque eu vou ter

que criar podes a mais para ele depois eliminar os antigos e é importante também né você já deve ter pescado aqui a ideia de que quanto maior aqui são esses valores mais rápida vai ser a troca de versão porque eu vou estar eliminando ali os Pods criando Pods novos e aí o processo é mais rápido quanto menor for aqui o valor mais lento é o processo e além do da porcentagem aqui que eu tô trabalhando com porcentagem eu posso botar uma quantidade fixa de Pods eu posso colocar aqui um pod no maxan available ou um

um um POD só no Max surge certo então é assim que funciona o h update strategy vamos ver como é que esse cara funciona aqui Vamos definir aqui pra gente ver a troca de versão com mais detalhes mas antes eu vou fazer o seguinte eu vou botar aqui o bu de novo tá pra gente voltar a versão e eu vou fazer aqui um pouquinho diferente eu vou executar aqui o Cub CTL apply de novo menos F deployment certo ah não fiz besteira de Deixa eu voltar aqui pra gente ver esse cara acontecendo né vou ver

aqui Green certo vou botar aqui né voltei e agora eu vou executar de novo só que aqui eu vou botar e o Watch pra gente ver esse cara trocando Cub CTL get po e a gente vai ver ele fazendo a troca aqui na prática e vendo a velocidade que isso acontece vou botar aqui de novo o Blue e vamos lá vamos ver aqui ah lá você vê que ele vai trocando aqui aos poucos né E foi lá terminou no caso aqui como eu tô trabalhando com 25% 25% de 10 aqui vão ser dois né eu

vou trabalhar aqui com dois podes sempre sendo eh trocados certo eh legal então agora o que que vai acontecer eu vou voltar aqui né então ele teve e dois para matar né O Max unavailable e o Max surge né criou mais dois ali Então na verdade eu tava trabalhando ali com troca de quatro em quatro né Mais ou menos Então agora eu vou fazer o seguinte eu vou vir aqui no Manifesto do kubernetes e eu vou trocar isso aqui é importante né que o strategy Né o Rolling update eu vou mexer nele aqui né no

meu na minha especificação do deployment né porque isso faz parte do deployment então eu vou fazer aqui né a definição do strategy eu vou definir o Type como Rolling update certo ring ring update certo e aqui embaixo né eu vou colocar o Rolling update strategy né ou melhor a estratégia aqui de atualização botar aqui ó ring update né E aí eu vou definir o maxge e o Max unavailable Max eh surge certo e aqui o Max unavailable esses dois carinhas como eu disse eu posso colocar aqui zero né no Max surge e o Max an

vable Vou botar aqui 25% certo vou começar aqui com 25% E se eu vir aqui agora e executar o Cub CTL apply Men F deployment Eu não mudei nada né ele ainda vai est aqui com os Pods certo aqui ó vai tá aqui com Pods mas se eu vir aqui Cub CTL describe deployment certo ah botar aqui Ah já foi aqui né deveria colocar aqui o nome mas aí listou todo só tem um não tem problema mas aqui ó se eu colocar aqui ó o strategy Type Rolling update tá aqui o mínimo como aqui no

caso ó O Max unviable tá aqui como 25% e aqui o Max surge como Zero Certo com esse carinha aqui então agora você vai ver que o processo vai ser mais lento deixa eu ver aqui né Vou botar aqui como Green certo e agora eu vou executar esse cara aqui vamos lá botar aqui o Watch beleza aqui ó aíe vai ali mais ou menos de dois em dois ó lá Vai terminando e vai criando á terminou e vai criando você vê que o processo ele já demorou um pouquinho mais e agora eu vou fazer o

seguinte eu vou mudar aqui o 25% e vou botar um só ele vai de um em um E aí eu vou botar aqui pro Blue certo vou executar aqui apply novamente vamos ver aqui o processo lá ele vai de um em um á você vê que aí você vê que olha só o processo tá muito mais demorado ele tá fazendo ali a troca de um em um Beleza então a gente consegue ter esse controle mais refinado no Deploy percebe como é que isso é importante quando a gente quer entregar aplicações escaláveis de grande porte e

ambientes onde eu preciso ter esse controle do ambiente não é simplesmente pegar a aplicação rodar lá cubc Aleluia Putz e tá tudo funcionando não a gente precisa pensar nessas estratégias Isso é o que diferencia o profissional que simplesmente Faz o arroz com feijão com um profissional que cara controla real ente as aplicações consegue trabalhar com aplicações escaláveis de Grand porte consegue trabalhar bem com as tecnologias aquele profissional cara de Elite que domina Cloud e devops e eu quero que você seja esse profissional então por isso que a gente tá vendo aqui passo a passo como

é que funciona essa troca e aí se eu quiser realmente fazer uma troca aqui Putz mais bruta eu posso botar aqui bruta não né mais rápida né utilizando aqui mais curso e tal eu posso colocar aqui ó 5 c aí vai fazer a troca aqui rapidinho certo eu venho aqui á Opa faz certo dá certo né não não coloquei aqui eh a versão nova boto aqui ó grein aí eu quero fazer aqui a troca rapidinho ele vai lá pá Ó lá ele já vai fazer aqui rapidamente você vê que pum rapidinho em alguns segundos ele

já trocou aqui a versão e a gente tem aqui tudo funcionando mas o legal aqui é que Independente de como você vai configurar o Rolling update você vai ter aqui uma indisponibilidade zero pro cliente Porque mesmo que eu coloque aqui ó o Max surge como um e o Max unavailable aqui o Max surge como zero e o Max unavailable como um né que é assim a forma mais lenta de fazer esse Deploy Ou trocando mesmo né Deixa eu trocar aqui vamos botar aqui o maxge um e o Max avaiable como um E se eu executar

aqui né e ir lá pra minha aplicação aqui não vai acontecer nada porque eu não atualizei né aqui no caso eu tô no Green né e eu vou vir aqui agora vou botar aqui o Boom certo e a gente vai executar aqui a atualização ele vai começar e e mesmo com essa com esse processo mais lento lá eu consigo né fazer aqui a requisição ele tá trocando aqui as réplicas ele tá atualizando a minha aplicação mas eu não tenho indisponibilidade ele vai alternando Claro ali do antigo pro novo mas eu não tenho indisponibilidade meu cliente

o máximo que pode acontecer é ele ver Putz pera aí a versão aqui tá mudando e tal que tem como a gente utilizar outras ferramentas como o ISO uma ferramenta de service me para fazer esse controle tá esse direcionamento de de tráfego para garantir que ele não vai ficar indo ali o tempo inteiro para várias instâncias e aqui ele vai ele não vai deixar de ter uma experiência boa utilizando a aplicação porque aí não vai ter a indisponibilidade certo é claro que também assim essa essa atualização que eu fiz é muito bruta né tá mudando

de azul para verde a gente tem esse Impacto mas quando se trata de simplesmente ali algum campo ou uma mudança mais sensível né mais Sutil né o usuário não vai sentir tanto essa mudança né Então depende do impacto que você tá tendo de atualização mas cara não tem disponibilidade certo e agora né bom você já entendeu aqui como funciona o roling update mas eu tenho aqui uma outra estratégia que eu posso utilizar né que ela não é aqui por padrão Ainda bem né inclusive que é o recreate o recreate ele vai fazer a atualização de

uma forma em que o meu usuário ele vai ter ali uma indisponibilidade porque diferente aqui do ring update onde eu faço essa troca aqui progressiva né eu vou eliminando aqui os Pods e vou criando os novos aqui no repc set novo ele vai fazer o seguinte ele vai matar todo todos os Pods antigos e aí assim que todos os Pods antigos tiverem sido eh eliminados ele vai criar aqui os novos por isso que é o recreate né E tá recriando ali e a minha aplicação E aí essa forma de atualização ela ela vai ter o

Down time certo mas você não vai ter recurso computacional Extra ali sendo utilizado e você pode utilizar para cenários menos críticos onde você pode ter ali uma certa indisponibilidade ou até para um ambiente de teste né Putz um ambiente de teste de desenvolvimento ficar indisponível ali por um tempo para economizar recurso computacional não é um problema então você pode utilizar Sem problema você não precisa condenar aqui o recreate você pode utilizar desde que você use da maneira correta então para trabalhar com recreate você vem aqui ó muda aqui para recreate certo e aqui a gente

vai fazer aqui a criação dele vamos a utilização dele eu vou executar aqui o apply né E no caso aqui eu não alterei de propósito só para atualizar aqui o a estratégia deixa eu mostrar aqui cubc describe Deploy certo e aí a gente vai ver aqui ó ah agora cadê Aqui ó ó o strategy Type é recreate você vê que a o maxge Max unavailable nem aparecem mais aqui né então agora eu vou fazer aqui o seguinte eu vou mudar do Blue pro Green e a gente vai ver aqui e o processo todo rolando vou

executar aqui apply Deploy vamos ver Ah lá ó ele termina tudo e aí depois ele cria novamente e aí se eu viro aqui ah lá já foi pro Green agora se eu vir aqui ó e botar o Blue de novo eu Vou atualizar certo aplico aqui ah lá ele vai começar E aí que que acontece aqui ah lá ó a minha aplicação ela tem Down time porque ele tá matando tudo para depois botar na a nova versão ó o tempo que eu fico aqui de indisponibilidade ó lá até a minha aplicação voltar então você pode

utilizar o ring update que já vem por padrão utilizando 25% de Max unavailable e 25% de Max search você pode utilizar aqui o Create para cenários onde você pode ter indisponibilidade né Você pode ter a sua aplicação ali fora do ar por um tempo ou você pode utilizar ali O Rol update fazendo ali um refinamento né aumentando ou diminuindo o Max unavailable e o Max surge para você ter ali e uma economia de recurso computacional ou aumentar ali a velocidade de troca de versão Show de bola então espero que esse vídeo tenha ajudado você a

entender mais sobre as estratégias de atualização e do kubernet para atualizar as suas aplicações se esse conteúdo te ajudou tá fazendo a diferença na sua carreira Coloca aí embaixo nos comentários # rumo à Elite que eu quero ter seu feedback eu tô aí conferindo os comentários e não deixa de dar um like no vídeo pro YouTube entender que esse conteúdo é de qualidade Vale a Pena Ser distribuído e também pega o vídeo compartilha nas suas redes sociais principalmente no Linkedin para que a sua rede veja que você tá se especializando que você tá afiando o

machado que você quer ser um profissional de Elite isso vai aumentar a sua visibilidade principalmente com os recrutadores e as recrutadoras certo e se você quer saber mais sobre a formação da vops pro que é o meu treinamento onde você aprende não só kubernetes mas diversas ferramentas do ecossistema de cloud de devops tem aí o formulário só preencher que a gente vai entrar em contato com você e entender o seu momento certo bom eu me despeço aqui show de bola Espero que você tenha gostado do vídeo Um abraço e até o próximo valeu