Introdução
Um cluster Kubernetes é como um grande edifício de apartamentos.
Se todos morassem no saguão, seria um caos. Você não saberia a quem pertence cada móvel, e um vizinho barulhento poderia incomodar todo mundo.
Os Namespaces particionam logicamente um cluster para que diferentes equipes, ambientes ou aplicações possam organizar seus recursos separadamente.
As ResourceQuotas limitam a quantidade de determinados recursos que um namespace pode consumir. Isso ajuda a evitar que uma equipe ou carga de trabalho esgote a capacidade compartilhada do cluster.
Neste laboratório, você vai:
- Construir um novo “apartamento” (Namespace) chamado
dev. - Definir um “limite de eletricidade” rigoroso (ResourceQuota) para esse apartamento.
- Tentar levar móveis (Pods) para o apartamento e verificar se eles cabem.
Criar um Namespace
Nesta etapa, você criará um novo namespace para isolar os recursos de uma equipe de desenvolvimento.
Um namespace é uma fronteira lógica dentro de um único cluster, não um cluster separado. As equipes continuam compartilhando o mesmo control plane e os mesmos nós subjacentes, mas nomes, políticas e várias visualizações de recursos podem ser separados para manter o trabalho organizado.
Por padrão, tudo vai para o namespace default (o saguão). Veja quais namespaces existem atualmente:
kubectl get namespaces
Você deverá ver default, kube-system (onde ficam os administradores do edifício) e alguns outros namespaces.
Agora, construa o apartamento dev:
kubectl create namespace dev
Verifique se ele existe:
kubectl get namespaces
Você verá dev na lista. No momento, ele é um apartamento vazio, sem paredes nem limites: você pode colocar qualquer coisa dentro dele.
Aplicar limites de recursos
Agora precisamos definir as regras. Não queremos que a equipe dev consuma toda a CPU e a memória do cluster.
Vamos criar um objeto ResourceQuota. Ele permite dizer: “No namespace dev, você pode usar no máximo 2 CPUs e 2Gi de memória”.
As cotas são especialmente importantes em clusters compartilhados porque CPU e memória são recursos finitos. Sem cotas, uma carga de trabalho muito intensa pode consumir mais do que sua parcela justa e tornar o cluster pouco confiável para todos os demais. Nesse sentido, as cotas não servem apenas para controle de consumo. Elas também são uma ferramenta de estabilidade.
Crie um arquivo chamado quota.yaml:
nano quota.yaml
Cole a configuração a seguir:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
Salve e saia (Ctrl+X, Y, Enter).
Aplique esta regra ao cluster:
kubectl apply -f quota.yaml
Você pode consultar os detalhes da regra. Eles mostrarão o limite “Hard” (o valor definido) e a quantidade “Used” (atualmente 0).
kubectl describe resourcequota dev-quota --namespace=dev
Implantar um Pod
Agora que as regras estão definidas, vamos tentar nos mudar.
Regra crítica: quando um apartamento tem um limite, cada móvel que você levar para dentro precisa ter seu tamanho declarado. Nos termos do Kubernetes: se um Namespace tiver uma Quota, cada Pod deverá especificar resources explicitamente (requests e limits). Se você não fizer isso, o administrador do edifício (Kubernetes) bloqueará sua entrada.
É aqui que duas ideias relacionadas se encontram. Um request informa ao scheduler de quantos recursos o Pod deve ter garantia quando for colocado. Um limit é a quantidade máxima de recursos que o contêiner pode usar. As quotas somam esses requests e limits em todo o namespace para manter o total dentro da política.
Crie um arquivo chamado pod.yaml:
nano pod.yaml
Cole o conteúdo a seguir. Observe que declaramos explicitamente o tamanho deste pod:
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
Salve e saia (Ctrl+X, Y, Enter).
Implante o Pod:
kubectl apply -f pod.yaml
Verifique se ele está em execução dentro do namespace dev:
kubectl get pods --namespace=dev
Aguarde até ver Running.
Agora, consulte novamente o uso da Quota. Você verá que a coluna “Used” aumentou.
kubectl describe resourcequota dev-quota --namespace=dev
Você está acompanhando com sucesso o uso dos recursos em relação ao seu orçamento.
Verificar o isolamento
Por fim, vamos verificar se as “paredes” do nosso “apartamento” são reais.
O isolamento de namespaces está principalmente relacionado a nomes, políticas e escopo das operações. Por padrão, isso não significa que as cargas de trabalho estejam executando em hardware fisicamente separado. Essa distinção será importante mais adiante, quando você aprender sobre seleção de nós e mecanismos de isolamento mais fortes.
Colocamos dev-pod dentro de dev. Ele não deve ficar visível no saguão (default).
Liste os Pods no namespace default:
kubectl get pods
Você deverá ver “No resources found in default namespace” (ou, pelo menos, não deverá ver dev-pod).
Agora, procure a Quota no namespace default:
kubectl get resourcequota
Você não deverá ver nada. O limite de eletricidade que definimos se aplica somente ao apartamento dev, não ao edifício inteiro.
Isso confirma que os Namespaces fornecem isolamento real para suas equipes.
Resumo
Neste laboratório, você se tornou o administrador do edifício do seu cluster Kubernetes.
Você conseguiu:
- Construir um Namespace privado (
dev) para uma equipe. - Definir uma ResourceQuota rigorosa (limite de eletricidade) para evitar o consumo excessivo.
- Implantar uma aplicação que respeitou esses limites.
- Verificar que as paredes entre os namespaces mantiveram os recursos isolados.
É assim que grandes organizações compartilham um único cluster Kubernetes entre centenas de equipes sem que elas atrapalhem umas às outras.
