Alura > Cursos de DevOps > Cursos de Containers > Conteúdos de Containers > Primeiras aulas do curso Google Kubernetes Engine: avançando com GKE

Google Kubernetes Engine: avançando com GKE

Aplicações stateless - Apresentação

Tudo bem? Vamos dar início à segunda parte do nosso curso de Kubernetes dentro da Google Cloud? Se você está chegando aqui e não viu a primeira parte, lá nós aprendemos a colocar a nossa aplicação, subir imagem, usar serviços dentro do Google Cloud, correlacionados ao Kubernetes, e fazer a administração. Qual é essa administração?

Gerenciar o pod, fizemos o deploy, gerenciamos serviço, criamos o load balance, fizemos várias atividades para podermos colocar a nossa aplicação, subir o nosso docker, a nossa imagem, e trabalhar com ela dentro da nuvem do Google Cloud. O que vamos fazer agora? Vamos escalar esse conhecimento.

Então vamos pegar agora e trabalhar com cenários diferentes. Vamos pegar uma aplicação totalmente stateless, botar ela funcionando, vamos pegar aqui um outro exemplo, onde precisa de persistência de disco e vamos ver os recursos do Kubernetes usando disco persistente.

Vamos ver a parte de auto scaling usando logicamente as ferramentas que o Google nos oferece, para podermos dar um passo além e evoluir no uso do Kubernetes. Pronto para começar? Eu sou o Ricardo Merces e quero te dar as boas-vindas a mais esse curso. Então vamos trabalhar.

Aplicações stateless - Criando uma app stateless

Para começarmos a trabalhar, qual é a ideia da aplicação? Qual é a ideia que vamos provisionar? Vamos fazer aqui, vamos jogar dentro do nosso Kubernetes um livro de visitas. Esse livro de visitas, ele tem uma particularidade de ter um front-end, com PHP e tudo mais. Esse front-end está apontando para um Redis, aquele banco de dados para podermos fazer esse controle.

Essa aplicação, ela é toda stateless, eu não vou me preocupar, por enquanto, com persistência de disco, nós vamos estudar isso mais tarde. Esse é o cenário que queremos montar. Então vamos detalhar, vamos começar, logicamente, na visão do usuário. O meu usuário chegou, ele bate no meu load balancer.

Load balance, já aprendemos, parte 1, vamos subir um serviço de load balance apontando para o nosso front-end. Nós vamos pegar as imagens, subir, fazer alguns ajustes. No front-end, nós já veremos uma parte legal de alocação de memória, alocação de recursos de CPU, que não vimos na parte 1, então já começa com novidade, vamos trabalhar com isso aqui.

Eu terei também, aqui no meu back-end, eu terei o meu Redis para suportar o esse livro de visitas. Então esse cenário para que você tenha em mente, e vamos começar a fazer o deploy, vamos comentando, vamos discutindo alguns aspectos, algumas dicas, como podemos fazer isso dentro do Google. Vamos lá, vamos começar. O que eu vou fazer?

Eu vou logar na minha conta, no console da Google Cloud, "console.cloud.google.com". Você faz o login na sua conta, nós caímos no nosso dashboard, no console, para trabalharmos.

Nós começamos da seguinte maneira, vamos criar logo um cluster. Eu tenho que ter um cluster para abrigar essa minha aplicação. Está lembrado dos tipos de clusters que nós já aprendemos aqui? Vamos voltar, eu venho no menu do Google Cloud Platform, "Kubernet Engine > Clusters". O que ele carrega para mim?

Vamos criar um cluster. “Ricardo, lembrei da tela, já tem um tempo que eu fiz a parte 1, estou voltando agora, mas lembrei, o ‘Standard’ e o ‘Autopilot’”.

Rapidamente, o standard nós já vimos, eu tenho a gerência dele, eu digo a quantidade de nós, eu faço o ajuste fino, vamos dizer assim. E no autopilot, eu só vou dizer para ele: “use a zona tal, a localidade que eu quero provisionar o meu cluster e você administra esse negócio para mim”.

Como assim, administra? A alocação de memória, de disco, tudo transparente. Então, para essa aplicação, vamos seguir o exemplo do "Autopilot". Eu vou configurar ele aqui. Lembrando também do seguinte, tem essa opção, que nós já aprendemos, e você também pode fazer o deploy de um autopilot pelo Shell. Nós não chegamos a fazer isso na parte 1, mas vamos tentar fazer aqui? Vamos abrir o Cloud Shell, está carregando.

Carregou aqui, demorou um pouco, carregou o Shell. O que vamos fazer? Vamos usar a linha de comando gcloud container, e a ideia é o "Tab", exatamente, container o que? gcloud container clusters, está lá. Eu vou dar um create. Olha que legal.

Create, tem a opção pura e a opção auto. Qual é a diferença? O auto, logicamente, do autopilot, e já fica a dica: “Ricardo, eu queria usar a linha de comando para criar do modelo do standard, é possível?”. Sim, é possível, bota o create, coloca nodes, o número de nós, pode colocar a zona, a região e tudo mais.

Nós combinamos que faremos o create-auto, ele vai reclamar aqui, vamos lá, gcloud container clusters create-auto, vamos lá, eu tenho que colocar o nome dele, create-auto guestbook, pode ser isso. Vamos ver se ele reclama mais uma vez, e o que ele vai reclamar.

Você tem que especificar a zona, a região. E é legal nós sempre aprofundarmos os conceitos. No caso, deixa eu voltar no Google Cloud Platform só para relembrarmos, se fossemos usar por aqui, a região – “ué, Ricardo, não aparece a zona?”.

Não aparece a zona, por quê? Porque o autopilot, ele tem a característica de ser um cluster regional. Por que regional? Para que ele tome conta da infra e provisione os nodes espalhados na zona, para manter a alta disponibilidade. Então, relembrando um ponto e aprofundando que a ideia da parte dos clusters regionais.

Aí vem aquelas siglas todas, "us-east1". Se você não se lembrar disso, tem sempre aqui, digite na busca "regiões e zonas", faça a procura no Google, tem a tabela aqui.

Então vamos usar, eu vou criar no "us-east1", mas vamos fazer pela nossa console. Repito o comando gcloud container clusters create-auto guestbook --region us-east1. Agora, vamos lá, está criando o cluster, isso demora um pouco.

Lembrando que quando fizemos pela console também demorou um pouco. Vou deixar ele fazendo esse processamento e volto, para começarmos a olhar os arquivos do deploy, fazer alguns comentários e subir o nosso guestbook. No próximo vídeo nós continuaremos.

Aplicações stateless - Deploy do Redis Master e Slave

Terminou a criação aqui, demorou um pouco, o mesmo tempo que demoraria no console. Nós vamos continuar da seguinte maneira, vamos aumentar essa tela para ficar a visualização melhor para mim e para você, e fazer o seguinte. Todo esse guestbook que eu comentei que isso tem na documentação do Google, então tem um GitHub deles que já tem esse projeto todo lá.

Vamos lá, pegar esse negócio, vou deixar o link do GitHub e também do ZIP dos arquivos que estamos trabalhando, então você pode fazer o download. Vamos dar uma olhada nesse GitHub, vamos pegar ele, deixa eu colar o link no navegador, só para entendermos.

Está aqui o link do GitHub e tem várias coisas legais, aqui dá até para explorar depois, mas vamos lá, eu vou copiar essa pasta, vamos no nosso Shell e vamos fazer um git clone e pegar desse link. Certo, e aí? Vamos olhar o que ele pegou. Está aqui, “Kubernetes-engine-samples”. O que eu quero daqui?

Eu quero isso aqui, guestbook. Para facilitar, mv guestbook/ .. para um diretório acima, está aqui, guestbook. É nele que vamos trabalhar. Você já sabe, vamos abrir o nosso editor e já apontamos para o guestbook.

"File > Open", olha o "guestbook" aqui. Vamos deixar esse console assim, para visualizarmos de uma forma mais confortável. Está carregando aqui. Está lembrando, a figura está aqui ainda? Está.

Vamos trabalhar no deploy primeiro do Redis, e abrimos o arquivo para vermos algumas particularidades. Eu vou pegar aqui o arquivo, olha quem está aqui. Temos o "redis-leader", o deploy do leader e temos, logicamente, o segundo.

Vamos pegar o "redis-leader-deployment" e dar uma examinada no arquivo. É o seguinte, o arquivo já está pronto, vem do fabricante, e vamos comentar as partes que são importantes. O que eu quero dizer? Primeira coisa, no caso do Redis, ele funciona com o master e com o slave, aqui ele está chamando de forma diferente, mas a temática é exatamente essa.

Ele tem o leader e o seguidor, é exatamente a mesma coisa, essa é a proposta de funcionamento do Redis. O que eu quero destacar aqui? Nós estamos criando um deploy, estamos utilizando um deploy, a imagem está aqui, image: "docker.io/redis:6.0.5", e isso é novo, cpu e memory.

Eu tenho aqui request de CPU e de memória. O que isso vai fazer? “Ricardo, eu já estudei sobre Kubernetes, já estudei isso tudo, e tenho uma vaga lembrança. Pode detalhar melhor?”. Vamos lá, quando colocamos essa requisição aqui, de CPU e de memória, você está dizendo para o Kubernetes, você está dizendo o teu cluster o seguinte: esse sujeito, o Redis, você vai alocar esse espaço de CPU e vai alocar isso de memória.

Isso é óbvio, é claro, eu sei que você já sabe. Só que tem um detalhe que às vezes a pessoa passa despercebido. Isso não só está alocando o recurso, mas também você não pode ultrapassar esse limite. Como assim? Eu estou dizendo que, em termos de unidade, 100m - você sabe que isso é contado em unidades dividido por dez.

Por exemplo, se eu precisasse alocar um core inteiro, eu ia dizer aqui: aloque mil, aí seria um core inteiro. Eu botei 100, então estou dividido por 10, eu estou pegando 1/10 avos do meu core, é isso o que eu quero alocar em termos de CPU.

O que acontece, o que temos que ficar atentos, por isso é sempre importante aprofundar os estudos, é o seguinte: se você, por acaso, se o Redis fosse exigir 200m, ou seja, o dobro dessa capacidade para ele subir, para operar, na hora que o contêiner for colocado no ar, daria um erro e ele não conseguiria fazer o provisionamento.

Então esses números, é importante sempre pensarmos que tem uma alocação, eu gosto de chamar dessa maneira, temos a alocação, mas também ele é um limitador de quanto você pode trabalhar. Isso é importante para a CPU, lembrando que, no caso, se eu quisesse um core, seria mil. Aqui eu estou com 1/10, eu dividi 1 por 10.

E a questão de memória, 100 mega são o suficiente para essa aplicação. Quem me disse isso? No detalhe da aplicação ele dá as especificações, nós colocamos exatamente isso. Diferente aqui também, esse serviço, o Redis que eu chamo de database, eu sei que tem quem não gosta disso e diz que é um armazenamento em memória. Para mim isso é database, enfim.

Ele está usando a memória, já reservamos os 100 mega, e ele está rodando como um serviço. O que eu quero dizer com isso? Que em algum momento o meu front-end vai falar com o meu Redis.

Como é que se fala com ele? Com uma porta TCP, é claro. A porta que ele funciona é essa 6379.

Eu não alterei nenhum default do que eu peguei, vou deixar esse ZIP para você, e vamos fazer o deploy desse sujeito, “redis-leader-deployment.yaml”. Então nós pegamos o nosso console e podemos fazer o seguinte, ls, está aqui. cd guestbook, ls, vamos ver o que ele cria, “redis-leader-deployment.yaml”, esse deploy aqui.

Vamos lá, kubectl apply -f e manda ele carregar esse sujeito. Vai fazer o deploy, vamos ver o que ele fez, kubectl get pods. Está criando o nosso contêiner. Enquanto ele cria o contêiner, vamos ver aqui, isso não deve demorar, running, já está pronto.

Assim como temos o pod rodando, precisaremos criar um serviço para controlar ele, até para que um fale com o outro, é a mecânica do Redis funcionar. Eu tenho aqui, ele chamou também, já está pronto, o arquivo de serviço. Não tem nada demais, ele só está dizendo o seguinte, que o meu controlador, ele vai apontar para a porta 6379.

Isso será responsável para ele poder gerenciar o leader, o slave, o serviço. Uma vez que fizemos do leader, vamos fazer o deploy do serviço do leader também. Voltou no console, estamos aqui: kubectl apply -f redis-leader-service.yaml. Vamos lá, kubectl get service, olha quem apareceu aqui, já está o controle dele, o leader já está aqui.

O que vamos fazer? Vamos repetir isso para o slave, para o seguidor. Voltamos para o editor e você verá que o arquivo é exatamente o mesmo. O seguidor, mesma alocação de memória, tudo mais.

A imagem que ele usa é diferente, Redis follower, e o outro é o Redis, cadê ele? Está vendo? Isso é importante.

Essas imagens eu não alterei nada, como eu já disse para você. O que é legal dessa parte é rever o conceito de alocação de memória, de CPU, tudo mais. Esse arquivo “redis-leader-deployment.yaml” é o deploy e esse “redis-leader-service.yaml” é o serviço.

Vamos lá, vamos fazer, vamos mandar isso rodar. Vamos no console, damos uma limpada, vamos fazer o nosso deploy. Vamos usar o kubectl apply -f redis-followe-deployment.yaml. Mandamos ele rodar, damos aquela olhada rápida se está tudo funcionando, kubectl get pods.

Os seguidores já estão sendo providenciados, pendentes. Vamos ver aqui, pending, pending. Nós fazemos assim, deixa eu esperar um pouco só e vou carregar aqui os serviços, vou fazer o deploy. Vamos esperar um pouco, vamos repetir o comando, agora já está tudo running.

Vale uma pausa rápida, para te lembrar o seguinte: isso aqui você pode detalhar o que está acontecendo, pegar as informações e também, lá no console, você pode acompanhar isso. Está lembrando do módulo 1? Esse cara, o guestbook, está aqui, olha o meu cluster.

Quanto está alocado, quanto está alocado de memória, e ele vai começar a alocar conforme a demanda, conforme o que formos utilizar. Está aqui, vamos abrir bem rápido, tem lá os detalhes, vamos ver os workloads.

Status ok, se der algum problema você também tem como monitorar por aqui, você já aprendeu isso. Mas vamos fechar essa parte, o que nós precisamos? Fizemos o deploy do Redis, do slave e eu preciso fazer agora aqui o do serviço. Fazemos o do serviço, kubectl get services.

Já está o serviço também, 6379, para podermos fazer o acesso a ele. Está pronto? Não. O que precisamos fazer? Nós criamos essa camada aqui, olha os serviços aqui.

Os serviços vão permitir, eu estou fazendo a exposição do meu pod para dentro do meu cluster. Se não, como eu iria acessar a porta de serviços? Isso foi resolvido, o que temos que fazer? Trabalhar no front-end, fazer o deploy do front-end, criar o load balance e ver isso tudo funcionando na prática. Na sequência eu volto para fazermos essa segunda etapa.

Sobre o curso Google Kubernetes Engine: avançando com GKE

O curso Google Kubernetes Engine: avançando com GKE possui 139 minutos de vídeos, em um total de 40 atividades. Gostou? Conheça nossos outros cursos de Containers em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Containers acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas