Saiba porque você não deve deixar de definir os recursos do seu Pod

Por Gaspar Barancelli Junior em 22 de fevereiro de 2023

Os recursos computacionais no contexto do Kubernetes são definidos como algo que pode ser requisitado, alocado e consumido por um contêiner.

Com base no contexto e detalhes de implementações da sua aplicação, você deve especificar a quantidade mínima e máxima de recursos necessários que sua aplicação pode consumir. Na especificação de um Pod você define a quantidade mínima de recursos no atributo requests, já a quantidade máxima no atributo limits.

A quantidade definida em requests é usada pelo escalonador do Kubernetes para colocar os Pods nos nós. Para acomodar um novo Pod, o escalonador aplica algumas regras para saber em qual nó o Pod pode ser acomodado, uma das regras aplicadas é que o nó tenha capacidade suficiente para subir este novo Pod e todos os seus contêineres, somando todas as quantidades requisitadas de recursos entre eles. Sendo assim, o campo requests de cada contêiner afeta o local em que um Pod poderá ser escalonado ou não. O exemplo a seguir mostra como esses limites são especificados para um Pod.

apiVersion: v1
kind: Pod
metadata:
  name: blog
spec:
  containers:
    - name: blog
      image: gasparbarancelli/blog:1.0
      resources:
        requests:
          memory: "200Mi"
          cpu: "200m"
        limits:
          memory: "400Mi"
          cpu: "400m"

Dependendo da especificação declarada, sendo ela requests, limits ou ambos, a plataforma oferecerá um tipo diferente de QoS (Qualidade de Serviço).

  • Best-Effort: Pod que não tem requests nem limits definidos em seus contêineres. Um Pod como esse é considerado como de mais baixa prioridade, e será encerrado antes se o nó em que o Pod foi colocado ficar sem recursos.

  • Burstable: Pod que tem requests e limits definidos mas com valores distintos. Um pod como esse tem garantias mínimas de recursos, mas também pode consumir mais recursos até seus limits forem atingidos. Quando o nó estiver sendo pressionado por recursos, esses Pods provavelmente serão encerrados, caso não haja outros Pods Best-Effort.

  • Guaranteed: Pod que tem uma quantidade igual de request e limits para os recursos. São os Pods de mais alta prioridade, e têm a garantia de que não serão encerrados antes dos Pods Best-Effort e Burstable.

As características dos recursos que você definir ou omitir para os contêineres terão um impacto direto em sua QoS e definirão a importância relativa do Pod caso haja falta de recursos.

// Livros recomendados relacionados ao assunto do post

// Compartilhe esse Post