instruction: Explain Sobrecarga de Pod
output: Este documento pode estar desatualizado
  Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada:
  Pod Overhead
  Sobrecarga de Pod
  ESTADO DA FUNCIONALIDADE:
  Kubernetes v1.18 [beta]
  Quando você executa um Pod num nó, o próprio Pod usa uma quantidade de recursos do sistema. Estes
  recursos são adicionais aos recursos necessários para executar o(s) contêiner(s) dentro do Pod.
  Sobrecarga de Pod, do inglês
  Pod Overhead
  , é uma funcionalidade que serve para contabilizar os recursos consumidos pela
  infraestrutura do Pod para além das solicitações e limites do contêiner.
  No Kubernetes, a sobrecarga de Pods é definido no tempo de
  admissão
  de acordo com a sobrecarga associada à
  RuntimeClass
  do Pod.
  Quando é ativada a Sobrecarga de Pod, a sobrecarga é considerada adicionalmente à soma das
  solicitações de recursos do contêiner ao agendar um Pod. Semelhantemente, o
  kubelet
  incluirá a sobrecarga do Pod ao dimensionar o cgroup do Pod e ao
  executar a classificação de prioridade de migração do Pod em caso de
  drain
  do Node.
  Habilitando a Sobrecarga de Pod
  Terá de garantir que o
  Feature Gate
  PodOverhead
  esteja ativo (está ativo por padrão a partir da versão 1.18)
  em todo o cluster, e uma
  RuntimeClass
  utilizada que defina o campo
  overhead
  Exemplo de uso
  Para usar a funcionalidade PodOverhead, é necessário uma RuntimeClass que define o campo
  overhead
  Por exemplo, poderia usar a definição da RuntimeClass abaixo com um agente de execução de contêiner virtualizado
  que use cerca de 120MiB por Pod para a máquina virtual e o sistema operacional convidado:
  kind
  RuntimeClass
  apiVersion
  node.k8s.io/v1beta1
  metadata
  name
  kata-fc
  handler
  kata-fc
  overhead
  podFixed
  memory
  "120Mi"
  "250m"
  As cargas de trabalho que são criadas e que especificam o manipulador RuntimeClass
  kata-fc
  irão
  usar a sobrecarga de memória e cpu em conta para os cálculos da quota de recursos, agendamento de nós,
  assim como dimensionamento do cgroup do Pod.
  Considere executar a seguinte carga de trabalho de exemplo, test-pod:
  apiVersion
  kind
  metadata
  name
  test-pod
  spec
  runtimeClassName
  kata-fc
  containers
  name
  busybox-ctr
  image
  busybox
  stdin
  true
  true
  resources
  limits
  500m
  memory
  100Mi
  name
  nginx-ctr
  image
  nginx
  resources
  limits
  1500m
  memory
  100Mi
  No tempo de admissão o
  controlador de admissão
  RuntimeClass
  atualiza o
  PodSpec
  da carga de trabalho de forma a incluir o
  overhead
  como descrito na RuntimeClass. Se o
  PodSpec
  já tiver este campo definido
  o Pod será rejeitado. No exemplo dado, como apenas o nome do RuntimeClass é especificado, o controlador de admissão muda o Pod de forma a
  incluir um
  overhead
  Depois do controlador de admissão RuntimeClass, pode verificar o
  PodSpec
  atualizado:
  kubectl get pod test-pod -o
  jsonpath
  '{.spec.overhead}'
  A saída é:
  map[cpu:250m memory:120Mi]
  Se for definido um
  ResourceQuota
  , a soma das requisições dos contêineres assim como o campo
  overhead
  são contados.
  Quando o kube-scheduler está decidindo que nó deve executar um novo Pod, o agendador considera o
  overhead
  do pod,
  assim como a soma de pedidos aos contêineres para esse
  . Para este exemplo, o agendador adiciona as requisições e a sobrecarga, depois procura um nó com 2.25 CPU e 320 MiB de memória disponível.
  Assim que um Pod é agendado a um nó, o kubelet nesse nó cria um novo
  cgroup
  para o Pod. É dentro deste Pod que o agente de execução de contêiners subjacente vai criar contêineres.
  Se o recurso tiver um limite definido para cada contêiner (
  garantida ou
  Burstrable QoS
  com limites definidos),
  o kubelet definirá um limite superior para o cgroup do Pod associado a esse recurso (cpu.cfs_quota_us para CPU
  e memory.limit_in_bytes de memória). Este limite superior é baseado na soma dos limites do contêiner mais o
  overhead
  definido no
  PodSpec
  Para CPU, se o Pod for QoS garantida ou
  Burstrable QoS
  , o kubelet vai definir
  cpu.shares
  baseado na soma dos
  pedidos ao contêiner mais o
  overhead
  definido no
  PodSpec
  Olhando para o nosso exemplo, verifique as requisições ao contêiner para a carga de trabalho:
  kubectl get pod test-pod -o
  jsonpath
  '{.spec.containers[*].resources.limits}'
  O total de requisições ao contêiner são 2000m CPU e 200MiB de memória:
  map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi]
  Verifique isto comparado ao que é observado pelo nó:
  kubectl describe node | grep test-pod -B2
  A saída mostra que 2250m CPU e 320MiB de memória são solicitados, que inclui
  PodOverhead
  Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
  --------- ---- ------------ ---------- --------------- ------------- ---
  default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m
  Verificar os limites cgroup do Pod
  Verifique os cgroups de memória do Pod no nó onde a carga de trabalho está em execução. No seguinte exemplo,
  crictl
  é usado no nó, que fornece uma CLI para agentes de execução compatíveis com CRI. Isto é um
  exemplo avançado para mostrar o comportamento do
  PodOverhead
  , e não é esperado que os usuários precisem verificar
  cgroups diretamente no nó.
  Primeiro, no nó em particular, determine o identificador do Pod:
  # Execute no nó onde o Pod está agendado
  POD_ID
  sudo crictl pods --name test-pod -q
  A partir disto, pode determinar o caminho do cgroup para o
  # Execute no nó onde o Pod está agendado
  sudo crictl inspectp -o
  json
  $POD_ID
  | grep cgroupsPath
  O caminho do cgroup resultante inclui o contêiner
  pause
  do Pod. O cgroup no nível do Pod está um diretório acima.
  "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a"
  Neste caso especifico, o caminho do cgroup do Pod é
  kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2
  . Verifique a configuração cgroup de nível do Pod para a memória:
  # Execute no nó onde o Pod está agendado
  # Mude também o nome do cgroup para combinar com o cgroup alocado ao Pod.
  cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes
  Isto é 320 MiB, como esperado:
  Observabilidade
  Uma métrica
  kube_pod_overhead
  está disponível em
  kube-state-metrics
  para ajudar a identificar quando o
  PodOverhead
  está sendo utilizado e para ajudar a observar a estabilidade das cargas de trabalho
  em execução com uma sobrecarga (
  Overhead
  ) definida. Esta funcionalidade não está disponível na versão 1.9 do kube-state-metrics,
  mas é esperado em uma próxima versão. Os usuários necessitarão entretanto construir o kube-state-metrics a partir do código fonte.
  Próximos passos
  RuntimeClass
  PodOverhead Design
  Comentários
  Esta página foi útil?
  Obrigado pelo feedback. Se você tiver uma pergunta específica sobre como utilizar o Kubernetes, faça em
  Stack Overflow
  Abra um bug no repositório do GitHub se você deseja
  relatar um problema
  sugerir uma melhoria
  Última modificação July 13, 2022 at 3:11 PM PST:
  Fix links to PodOverhead Feature Design (language/pt) (e8f9fd5334)