Saiba porque você não deve deixar de definir os recursos do seu Pod
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.