Kubernetes do Zero - Parte 4: Pods e Limites de recursos

Fala galera, td bem?

Retomando nossa sequência sobre kubernetes do zero, hoje falamos falar sobre Pods e Limites de Recursos.

PODs

Quando falamos de qualquer componente do kubernetes, o Pod é a menor unidade que podemos ter dentro do nosso cluster.

Dentro do kubernetes, o Pod é o objeto que pode conter um ou mais containers, compartilhando os mesmos recursos como IP, namespace, volume e para resumir, tudo que for relacionado a este Pod.

Vamos ver alguns exemplos de como criar um Pod no nosso cluster.

Inicialmente para criarmos um Pod, podemos executar direto pela linha de comando.

kubectl run webapp --image=nginx --port=80

Esse comando faz com que seja criar um Pod chamado webapp com a imagem do nginx expondo o serviço na porta 80.

Dando tudo certo com o comando "run", teremos uma saída informando que o pod foi criado:

Para consultar se ele foi criado de fato e qual o seu STATUS, devemos rodar o comando:

kubectl get pods

Explicando a saúda do "kubectl get pods":

• Name - o nome que demos para nosso Pod
• READY - aqui está 0/1 por que o Pod ainda está sendo criado efetivamente (baixando a imagem, aplicando IP, etc). Quando estiver pronto, o Ready ficará 1/1 ... pois foi solicitado apenas 1 Pod, então o esperado é isso 1/1
• STATUS - será o nosso principal ponto de acompanhamento. Aqui teremos as mensagens iniciais de erro caso seja encontrado algum problema, se ele ainda está sendo criado, se foi criado com sucesso
• RESTARTS - Muitas vezes podemos ter cenários de problemas/erros que fazem com que o Pod fique reiniciando. Se esse "count" começar a sofrer incrementos é sinal de problema
• AGE - por quanto tempo o Pod está disponível desde que começou a ser criado.

Passando um curto intervalo de tempo, rodando novamente o "kubectl get pods", devemos ter a saída abaixo:

• READY - 1/1
• STATUS - Running

E o melhor de tudo, sem RESTARTS.

Um ponto de atenção...

Muitos clusters kubernetes trabalham com namespaces, então ao rodar o comando "kubectl get pods" fará a busca de recursos no namespace padrão. Aqui no nosso caso, criamos nosso Pod dentro do padrão mesmo, por isso o comando retornou algo.

Veremos o tema namespace mais pra frente.

Mas só para já irmos nos familiarizando, caso seja necessário em um cluster novo que não conhecemos por exemplo, podemos rodar o seguinte comando:

kubectl get pods -A

Veja agora com a opção "-A" a quantidade de Pods que retornou. Mas ali, na primeira coluna temos o detalhe de onde cada Pod está residindo.

Outra forma de ter essa mesma saída é com o comando:

kubectl get pods --all-namespaces

Ou se quisermos diretamente os Pods de um respectivo namespace:

kubectl get pods -n Nome_Do_Namespace

Exemplo, só os Pods do namespace kube-system:

kubectl get pods -n kube-system

Legal... Mas, eu tenho como ver onde o Pod está rodando? Saber em qual node do cluster, se ele pegou um IP e qual IP é esse...

Tem sim.

Para isso, vamos executar o comando:

kubectl get pods -o wide

Nosso Pod webapp está residindo no node "k8s-kind-worker" e tem o IP 10.244.1.6.

Podemos também ter uma saída com informações mais descritivas do nosso Pod, com o seguinte comando:

kubectl describe pods webapp

Ele trás as mesmas informações que os comandos get, porém, podemos ver o ID do container que está em execução dentro deste Pod, a image, ID da imagem, um trecho do log de subida, etc.

Show de bola.

Mas e agora, como eu faço para deletar um Pod?

Pela linha de comando, seria assim:

kubectl delete pods Nome_Do_Pod

No nosso lab, vamos deletar o Pod webapp:

kubectl delete pods webapp

Como podemos confirmar com o comando "kubectl get pods" depois de rodar o delete ... Nosso Pod webapp não existe mais.

A outra forma de criamos Pods no kubernetes é através de manifestos, chamados mais tradicionalmente de arquivos YAML.

Um arquivo YAML (YAML Ain't Markup Language) é um documento de texto simples usado para armazenar e organizar dados de forma estruturada, com foco total na legibilidade humana.

Vejamos um exemplo:

apiVersion: v1 # versão da API do Kubernetes
kind: Pod # tipo do objeto que estamos criando
metadata: # metadados do Pod 
  name: webapp # nome do Pod que estamos criando
  labels: # labels do Pod
    run: webapp # label run com o valor webapp
spec: # especificações do Pod
  containers: # containers que estão dentro desse Pod
  - name: webapp # nome do container
    image: nginx # imagem do container
    ports: # portas que estão sendo expostas pelo container
    - containerPort: 80 # porta 80 exposta pelo container

A parte um pouco "chata" do uso dos YAMLs é que ele tem padrão e indentação. Então, quando estamos fazendo as criações de recursos por YAML (que é a forma correta e recomendada), devemos ficar sempre atentos a estrutura ... Com certeza até pegarmos a manha muitos erros vão ocorrer, até conseguirmos acertar tudo e assim os objetos serem criados.

Agora, vamos fazer um teste de criação do nosso pod webapp, usando esse YAML como base das informações.

Salve o conteúdo do arquivo.

Valide se está tudo OK:

Depois de criarmos o arquivo, para executar devemos rodar o comando:

kubectl apply -f create-pod.yaml

Dando tudo certo, a saída será:

E para ver se está tudo OK com o Pod:

kubectl get pods

Para deletá-lo, vale o mesmo comando que usamos de que usamos no nosso primeiro deploy do webapp.

kubectl delete pods webapp

Uma outra forma de fazermos isso, seria usando o delete mas informando o nome do arquivo que usamos para criação do Pod:

kubectl delete -f create-pod.yaml

Vamos ver um exemplo da criação de um Pod com mais de um container?

Vamos criar um arquivo chamado "create-pod-multcontainer.yaml".

O conteúdo dele será:

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    run: webapp
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
  - name: apache
    image: httpd:latest
    ports:
    - containerPort: 8080
    command: ["/bin/sh", "-c"]
    args:
      - |
        sed -i 's/Listen 80/Listen 8080/g' /usr/local/apache2/conf/httpd.conf
        httpd-foreground

Tanto Nginx como Apache HTTPD usam a mesma porta TCP/80, então se tetarmo subir os dois vamos tomar um erro. Por isso ao final, na configuração do container do Apache, vamos durante o processo de subida, já trocar o porta dele para 8080.

kubectl apply -f create-pod-multcontainer.yaml

Olha que top!!!

O STATUS está como Running e no READY vemos 2/2.

Mas como vamos ter a certeza que dentro do webapp temos um container do Nginx e um do Apache?

Com o describe, que aprendemos acima:

kubectl describe pods webapp

Não é muito comum vermos este tipo de cenário onde dentro de um Pod temos dois containers ... Mas dependendo, alguma aplicação pode ter essa necessidade.

E para deletar esse Pod multi-containers?

Mesma coisa que já vimos também. Podemos usar o comando "kubectl delete Nome_Do_Pod" ou "kubectl delete -f arquivo.yaml".

Escolha uma das opções e tente deletar o seu sozinho :)

Mas qualquer problema ou dúvida, é só comentar aqui no post. OK?

Aplicando limites de recursos (CPU e Memória)

Agora que vimos como subir nossos Pods, ou melhor, nossas aplicações ... Um problema muito comum que pode e vai acontecer, é o uso desenfreado de recursos.

Isso mesmo.

O processo de criação que usamos até aqui, não cria nenhum limite de recursos de CPU e memória aos nossos Pods e dependendo do que rode neles conforme for precisando de mais recursos, eles vão consumir e isso pode saturar nosso cluster, provisionar recursos a mais e gerar custos desnecessários. Principalmente quando falamos de recursos em Cloud.

Mas existe uma "mágica" interessante que podemos fazer ... a limitação de recursos.

Podemos e devemos, como parte de sermos bons administradores de kubernetes, limitar recursos dos Pods e irmos ajustando conforme necessidade. Isso nos dará informações para saber se uma determinada aplicação precisa ser melhor desenvolvida, trocar algum parâmetro dentro dela, se precisamos realmente colocar mais recursos em nosso ambiente para acomodá-la, etc.

E agora que sabemos que o correto é criar recursos no kubernetes usando manifestos YAML, vamos fazer isso dessa forma.

Exemplo do arquivo YAML que iremos usar no nosso lab:

apiVersion: v1 # versão da API do Kubernetes
kind: Pod # tipo do objeto que estamos criando
metadata: # metadados do Pod
  name: webapp # nome do Pod que estamos criando
  labels: # labels do Pod
    run: nginx # label run com o valor nginx
spec: # especificação do Pod 
  containers: # containers que estão dentro do Pod 
  - name: nginx # nome do container 
    image: nginx # imagem do container
    ports: # portas que estão sendo expostas pelo container
    - containerPort: 80 # porta 80 exposta pelo container
    resources: # recursos que estão sendo utilizados pelo container
      limits: # limites máximo de recursos que o container pode utilizar
        memory: "192Mi" # limite de memória que está sendo utilizado pelo container, no caso 192 megabytes no máximo 
        cpu: "0.5" # limite máxima de CPU que o container pode utilizar, no caso 50% de uma CPU no máximo
      requests: # recursos garantidos ao container
        memory: "128Mi" # memória garantida ao container, no caso 128 megabytes
        cpu: "0.3" # CPU garantida ao container, no caso 30% de uma CPU

Dentro de "resources" temos:

limitis:

  memory: "valor"

  cpu: "valor"

Aqui temos o máximo de recursos que este determinado Pod pode usar dos recursos do cluster.

requests:

  memory: "valor"

  cpu: "valor"

Da mesma forma que podemos limitar os recursos para que não seja usado tudo que tem no cluster, podemos informar ao kubernetes que uma determinada aplicação precisa garantir uma quantidade "mínima" de recursos obrigatórios para uma determinada aplicação.

Agora vamos subir nossa aplicação com limite de recursos e com a quantidade mínima de recursos que ela precisa.

Crie o arquivo "pod-limites.yaml" e cole o conteúdo de exemplo acima e aplique com o comando:

kubectl apply -f pod-limites.yaml

Vamos validar se os limites foram aplicados?

kubectl describe pods webapp

Rapaiiizzzz... e "num" é que deu certo =) ... Isso é lindo demais!!!

Agora, o legal é vc ir testando e aplicando tudo que aprendemos no seu lab. Tente subir um Pod com menos recursos como necessário e veja se ele sobe, tente subir vários Pods cada um com uma quantidade de recursos e veja como fica o comportamento do seu cluster ... a mágica agora é ir testando.

Se ficou alguma dúvida é só deixar aqui nos comentários.

Abs e até a próxima postagem.

:wq!