Bom pessoal, no nosso vídeo anterior eu mostrei como que a gente cria um cluster Kubernetes na nossa máquina utilizando o Kind. Mas agora o nosso principal objetivo é criar um pod aí para a gente. Lembrando que um pod é um encapsulamento de um container rodando que fornece para o Kubernetes uma interface para que o Kubernetes consiga gerenciar rede, gerenciar disco e muitos outros aspectos. Lembrando que, por padrão, os pods que a gente vai rodar, normalmente eles devem ficar nos nodes do Kubernetes e não no control plane. Porém, como a gente só está com um nó aqui na nossa máquina local, ele vai ser colocado dentro do control plane também. Legal? Bom, galera, o negócio é o seguinte, tá? Toda vez que a gente vai criar qualquer coisa no Kubernetes, no final das contas, a gente está trabalhando com elementos, com objetos do Kubernetes. E esses objetos do Kubernetes, quando aplicados ali, o Kubernetes vai chamar a API, baseado naquela declaração, ele vai executar os seus controllers, os schedulers, para conseguir? Que é o padrão que o Kubernetes utiliza e esse padrão aqui, o que que ele faz, tá? Nesse nosso caso, nós vamos criar um objeto aqui no Kubernetes chamado de pod, tá? E esse pod eu vou poder escolher qual o container que vai rodar dentro dele legal eu tenho uma extensão aqui do vscode para kubernetes tá então se você olhar aqui digitar kubernetes aqui no seu vscode você vai ter uma extensão que você pode fazer instalação essa extensão ela vai te ajudar a completar para você né esses principais objetos que você vai trabalhar com o Kubernetes. Eu vou utilizar o autocomplete dela, mas eu vou passar passo a passo aqui para você, linha a linha, sobre o que ela está querendo dizer. E de cara, se é a primeira vez que você está utilizando o Kubernetes, não se assuste, esses manifestos são um pouco grandes, mas tudo faz sentido na hora que você começa a se acostumar com ele. Então eu vou digitar pod aqui e você vai ver que a minha extensão já traz aqui o kubernetes pode então vou dar um enter e ele vai trazer aqui o nome é as configurações o meu pode eu vou substituir esses nomes por enginex tá então vamos começar do começo agora aqui pra você não se assustar. Legal? Então vamos lá. Lembra que eu falei que o Kubernetes, ele sempre vai ter a API dele? Essa API, ela é versionada, porque cada objeto, cada modificação que o Kubernetes vai tendo, a gente vai versionando na API, para ele conseguir ler determinados tipos de declaração. Então nesse nosso caso, a API version do Kubernetes que a gente está utilizando para um pod é a versão 1. Simples assim. Agora, um ponto importante aqui para você saber é a parte de kind. O kind é o tipo do objeto que você quer criar no Kubernetes. Kind, em inglês, é tipo. E aqui, o tipo do objeto que eu quero criar é um pod. Legal? Agora, o que acontece é o seguinte. Toda vez que você cria um objeto no Kubernetes, você quer passar algumas informações extras para ele, para que o Kubernetes utilize essas informações para se encontrar quando você vai ter diversos objetos relacionados. Essas informações ficam guardadas em metadados. Então, se você perceber, aqui nessa linha 3, eu tenho uma opção de metadata. E essa metadata aqui vai trazer alguns pontos importantes. Olha só que interessante. Dentro do metadata, eu tenho o name. Então, aqui vai ser o nome do objeto que a gente vai trabalhar. Legal? Eu dei o nome do objeto de Nginx, que vai ser o serviço que a gente vai subir. Uma outra coisa aqui também é que o Kubernetes, quando você cria qualquer tipo de objeto, você tem a opção de taguear esse objeto, ou seja, marcar esse objeto, adicionar uma etiqueta nesse objeto, para caso o Kubernetes for executar uma operação, você pode falar para ele executar uma operação onde as labels sejam XPTO. Legal? E por padrão aqui, a gente está criando uma label, ou seja, como se fosse uma etiqueta aqui para a gente no nosso pod, falando o seguinte, onde a propriedade name é Nginx. Simples assim, galera. Então, o metadata, que é o nome do meu pod, é Nginx, e eu criei uma label onde a chave é name e o valor é Nginx aqui para a gente. Somente isso até agora. Galera, uma outra coisa importante aqui para você. Você não precisa decorar essas paradas. Eu não decoro. Toda vez eu utilizo o autocomplete. Copio e colo de coisas que eu já tenho. Mas o importante é você entender a ideia. Legal? E a partir de agora, chega uma das partes mais importantes que a gente tem na declaração do nosso pod, que são as especificações. Por que especificações, galera? Porque todo pod vai ter uma especificação técnica do que vai rodar naquele pod. Então lembra que eu falei que todo pod possui um container rodando? Então dentro da especificaçãoação eu tenho aqui containers. Por que containers com S? Porque eu posso ter mais de um container rodando no mesmo pod, mas por convenção, salvo algumas regras, normalmente você tem um pod para um container. Então, nesse caso aqui, eu estou dando o nome para o meu container, que é Nginx, vou falar qual a imagem Docker que esse container vai utilizar, e eu vou utilizar a imagem padrão do Nginx, que é Nginx, dois pontos latest, tá? E aqui a gente começa com os pontos importantes, tá? E aqui a gente começa com os pontos importantes, que são os resources, ou seja, quais são os limites de recursos computacionais que eu vou dar por esse pod. Por exemplo, eu estou falando que no máximo esse pod vai gastar 128 MB de memória RAM e ele vai gastar no máximo 500 mili cores de CPU. Lembrando que mil mili cores é igual a um vCPU em qualquer cloud que você for trabalhar. Tá bom? Então o que acontece? Aqui tem os limites que vão acontecer. Um ponto importante é que quando a gente for falar sobre recursos, você vai ver que tem os limites mínimos e os máximos, etc. Mas isso aqui é somente para deixar claro para você. Quando você cria um pod, você pode estabelecer os limites de recursos computacionais que esse pod vai ser utilizado. Nesse nosso caso aqui, galera, eu vou até remover os resources porque não faz sentido para a demonstração que eu estou criando. Então, vou até remover esse cara aqui. E aqui, por último, eu tenho portas. O que isso significa? Significa o seguinte, qual porta o pod vai chamar o container? Lembrando, eu tenho o pod de um lado, eu tenho o container do outro. Para o pod conversar com o container, eu vou ter que falar qual porta o pod deve chamar o container. E daí, se você que desenvolveu aquele container, gerou a imagem do container, você vai saber qual a porta que você expõe. No caso do Nginx, por padrão, a porta é 80. Legal? Porque é um servidor web aqui pra gente. Então, galera, basicamente, com 12 linhas, a gente colocou a especificação aqui de um pod pra gente rodar no Kubernetes. Legal? Agora, como que eu consigo ver isso funcionando? Então, a gente vai fazer o seguinte, eu vou abrir meu terminal e eu vou dar um kubectl apply menos f, que é de arquivo, e eu vou falar qual é o arquivo que eu estou apontando, que é o pod.yaml. Vou dar um enter aqui, e ele falou o seguinte agora aqui para mim, está vendo? O pod, que é chamado de nginx, foi criado. E agora, como que eu sei que realmente isso foi criado? No vídeo anterior, eu dei um comando onde a gente lista todos os pods, está lembrado? Então, eu vou dar aqui um kubectl get pods, e ele vai trazer aqui para mim o seguinte, olha, eu tenho um pod chamado nginx, nesse pod eu tenho um container, e esse um container está rodando, ou seja, eu tenho um de um rodando, que está pronto. E o status aqui é que esse pod está em funcionamento, nunca houve reinício, e o tempo de criação dele faz 22 segundos. Se eu rodar de novo, você vai ver que o tempo de criação dele aqui aumentou. Então, com isso, galera, nós já fizemos o nosso primeiro ponto aqui com o Kubernetes, que é rodar um pod do Nginx aqui dentro. No próximo vídeo, o que eu quero trazer para você é como que eu consigo visualizar esse pod no meu navegador funcionando com o Nginx. Beleza? Um grande abraço e até o nosso próximo vídeo.