🥇Como acceder aos recursos de Kubernetes Pod

A recompensa de Tohad

Ao comezar a utilizar Kubernetes, é habitual esquecerse da configuración dos recursos do contedor. Neste punto, é suficiente para asegurarse de que a imaxe de Docker funciona e se pode implementar no clúster de Kubernetes.

Pero a aplicación posterior debe ser implantada nun clúster de produción xunto con outras aplicacións. Para iso, cómpre asignar recursos para o contedor e asegurarse de que hai suficientes para que a aplicación se inicie e se execute, e non haberá problemas noutras aplicacións en execución.

Equipo Kubernetes aaS de Mail.ru traduciu un artigo sobre recursos do contedor (CPU e MEM), solicitudes de recursos e límites. Aprenderá cales son os beneficios que proporcionan estas opcións de configuración e que ocorre se non están configuradas.

Recursos informáticos

Temos dous tipos de recursos coas seguintes unidades:

Unidade central de procesamento (CPU) - núcleos;
Memoria (MEM) - bytes.

Os recursos especifícanse para cada contedor. No seguinte ficheiro Pod YAML, verá unha sección de recursos que contén os recursos solicitados e limitados:

Recursos dos pods solicitados = suma dos recursos solicitados de todos os pods;
Límite de recursos de pod = Suma de todos os límites de recursos de pod.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

Exemplo de recursos solicitados e limitados

Campo resources.requested da especificación Pod - un dos elementos que se usa para atopar o nodo desexado. Xa podes programar unha implementación de Pod nel. Como atopar un nodo axeitado?

Kubernetes consta de varios compoñentes, incluíndo o nodo principal ou nodo mestre (Kubernetes Control Plane). Hai varios procesos no nodo mestre: kube-apiserver, kube-controller-manager e kube-scheduler.

O proceso kube-scheduler encárgase de mirar os pods recentemente creados e buscar posibles nodos de traballo que coincidan con todas as solicitudes de pods, incluído o número de recursos solicitados. A lista de nós atopados por kube-scheduler está clasificada. O pod está programado no nodo coas puntuacións máis altas.

Onde se colocará o Pod morado?

A imaxe mostra que o Kube-scheduler necesita programar un novo Pod morado. O clúster de Kubernetes contén dous nodos: A e B. Como podes ver, kube-scheduler non pode programar un Pod para o nodo A: os recursos dispoñibles (non solicitados) non coinciden coas solicitudes do Pod morado. Por exemplo, o 1 GB de memoria solicitado polo Pod morado non caberá no Nodo A, xa que a memoria dispoñible é de 0,5 GB. Pero o nodo B ten recursos suficientes. Finalmente, kube-scheduler decide que o destino do Pod morado é o nodo B.

Agora sabemos como afectan os recursos solicitados á elección dun nodo para executar un Pod. Pero cal é o efecto dos recursos marxinais?

O límite de recursos é un límite que a CPU/MEM non pode cruzar. Non obstante, o recurso da CPU é flexible, polo que os contedores que alcanzan os seus límites de CPU non provocarán que o Pod se apague. Pola contra, comezará a limitación da CPU. Se se alcanza o límite MEM, o contedor deterase debido a OOM-Killer e reiniciarase se o permite a configuración de RestartPolicy.

Recursos solicitados e limitados en detalle

Vinculación de recursos entre Docker e Kubernetes

A mellor forma de explicar como funcionan os límites solicitados e de recursos é imaxinar a relación entre Kubernetes e Docker. Na figura anterior, podes ver como están relacionados os campos de Kubernetes e as bandeiras de inicio de Docker.

Memoria: petición e límite

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

Como se mencionou anteriormente, a memoria mídese en bytes. Baseado en Documentación de Kubernetes, podemos especificar a memoria como un número. Normalmente é un número enteiro, por exemplo 2678, é dicir, 2678 bytes. Tamén podes usar sufixos G и Gi, o principal é lembrar que non son equivalentes. O primeiro é decimal e o segundo é binario. Como exemplo mencionado na documentación do k8s: 128974848, 129e6, 129M, 123Mi - Son practicamente equivalentes.

Parámetro Kubernetes limits.memory coincide coa bandeira --memory de Docker. En caso de request.memory non hai frecha para Docker porque Docker non usa este campo. Podes preguntar se isto é necesario? Si precisa. Como dixen antes, o campo é importante para Kubernetes. Baseándose na información da mesma, kube-scheduler decide en que nodo programar o Pod.

Que pasa se non hai memoria suficiente para a solicitude?

Se o contedor alcanzou os límites da memoria solicitada, entón o Pod colócase nun grupo de Pods que se deten cando non hai memoria suficiente no nodo.

Que pasa se estableces o límite de memoria demasiado baixo?

Se un contedor supera o límite de memoria, finalizará debido a OOM-Killed. E reiniciarase se é posible en función da RestartPolicy, onde está o valor predeterminado Always.

Que pasa se non especifica a memoria solicitada?

Kubernetes tomará o límite e establecerao como predeterminado.

Que pode pasar se non especificas un límite de memoria?

O recipiente non ten límites, pode usar tanta memoria como queira. Se comeza a usar toda a memoria dispoñible do nodo, entón OOM matará. O contedor reiniciarase se é posible en función da Política de reinicio.

Que pasa se non especificas límites de memoria?

Este é o peor dos casos: o planificador non sabe cantos recursos necesita o contedor e isto pode causar serios problemas no nodo. Neste caso, sería bo ter límites predeterminados no espazo de nomes (definidos por LimitRange). Sen límite predeterminado: o pod non ten límite, pode usar tanta memoria como queira.

Se a memoria solicitada é superior á que o nodo pode ofrecer, o Pod non se programará. É importante lembralo Requests.memory non é o valor mínimo. Esta é unha descrición da cantidade de memoria que é suficiente para manter o contedor funcionando todo o tempo.

En xeral, recoméndase establecer o mesmo valor para request.memory и limit.memory. Isto impide que Kubernetes programe un Pod nun nodo que teña memoria suficiente para executalo pero que non sexa suficiente para executalo. Ten en conta que a planificación de Kubernetes Pod só ten en conta requests.memoryE limits.memory non ten en conta.

CPU: solicitude e límite

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

Coa CPU, as cousas son un pouco máis complicadas. Volvendo á imaxe coa relación entre Kubernetes e Docker, podes ver iso request.cpu corresponde a --cpu-shares, mentres que limit.cpu coincide coa bandeira cpus en Docker.

A CPU solicitada por Kubernetes multiplícase por 1024, a proporción de ciclos de CPU. Se queres solicitar 1 núcleo completo, debes engadir cpu: 1como se mostra arriba.

Solicitar un núcleo completo (proporción = 1024) non significa que o teu recipiente o reciba. Se a súa máquina anfitrión só ten un núcleo e está a usar máis dun contenedor, todos os contenedores deben compartir a CPU dispoñible entre eles. Como ocorre isto? Vexamos a imaxe.

Solicitude de CPU - Sistema de núcleo único

Imaxinemos que tes un único sistema principal que executa contedores. Mamá (Kubernetes) fixo unha empanada (CPU) e quere compartila entre os seus fillos (envases). Tres fillos queren unha torta enteira (proporción = 1024), outro neno quere media torta (512). Mamá quere ser xusta e fai un cálculo sinxelo.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

Segundo o cálculo, tres nenos recibirán o 28% do núcleo, e non a totalidade. O cuarto fillo recibirá o 14% do núcleo completo, non a metade. Pero as cousas serán diferentes se tes un sistema multinúcleo.

Solicitude de CPU: sistema multinúcleo (4).

Na imaxe de arriba, podes ver que tres nenos queren unha empanada enteira e un quere a metade. Xa que mamá fixo catro empanadas, cada un dos seus fillos recibirá tantas como queira. Nun sistema multinúcleo, os recursos do procesador distribúense en todos os núcleos de procesador dispoñibles. Se un contedor está limitado a menos dun núcleo de CPU completo, aínda pode usalo ao 100 %.

Os cálculos anteriores simplifícanse para comprender como se comparte a CPU entre contedores. Por suposto, ademais dos propios contedores, hai outros procesos que tamén usan recursos da CPU. Cando os procesos dun contedor están inactivos, outros poden usar o seu recurso. CPU: "200m" corresponde a CPU: 0,2, o que significa aproximadamente o 20% dun núcleo.

Agora imos falar limit.cpu. A CPU que limita Kubernetes multiplícase por 100. O resultado é a cantidade de tempo que pode usar o contedor cada 100 µs (cpu-period).

limit.cpu coincide coa bandeira de Docker --cpus. É unha combinación nova do vello --cpu-period и --cpu-quota. Ao configuralo, especificamos cantos recursos de CPU dispoñibles o contedor pode maximizar antes de que comece a limitación:

CPU - combinación cpu-period и cpu-quota. cpus = 1.5 é equivalente á configuración cpu-period = 100000 и cpu-quota = 150000;
período de CPU - período Programador de CPU CFS, por defecto 100 microsegundos;
cpu-cota é o número de microsegundos dentro cpu-periodA que está restrinxido o recipiente.

Que pasa se instalas unha CPU insuficientemente solicitada?

Se o contedor necesita máis do que está configurado, roubará a CPU doutros procesos.

Que pasa se estableces un límite de CPU insuficiente?

Dado que o recurso da CPU é axustable, activarase a limitación.

Que pasa se non especificas unha solicitude de CPU?

Como no caso da memoria, o valor da solicitude é igual ao límite.

Que pasa se non especificas un límite de CPU?

O contedor usará tanta CPU como necesite. Se a política de CPU predeterminada (LimitRange) está definida no espazo de nomes, entón este límite tamén se usa para o contedor.

Que pasa se non se especifica nin a solicitude nin o límite de CPU?

Do mesmo xeito que coa memoria, este é o peor dos casos. O planificador non sabe cantos recursos necesita o teu contedor e isto pode causar problemas graves no nodo. Para evitar isto, cómpre establecer límites predeterminados para os espazos de nomes (LimitRange).

Lembre, se solicita máis CPU da que os nodos poden proporcionar, o Pod non se programará. Requests.cpu - non é o valor mínimo, senón un valor suficiente para iniciar o Pod e funcionar sen fallos. Se a aplicación non realiza cálculos complexos, a mellor opción é instalala request.cpu <= 1 e executa tantas réplicas como sexa necesario.

Cantidade ideal de recursos solicitados ou límite de recursos

Aprendemos sobre a limitación dos recursos informáticos. Agora toca responder á pregunta: "Cantos recursos necesita o meu Pod para executar a aplicación sen problemas? Cal é a cantidade ideal?

Desafortunadamente, non hai respostas claras a estas preguntas. Se non sabes como funciona a túa aplicación, canta CPU ou memoria necesita, a mellor opción é darlle moita memoria e CPU á aplicación, e despois executar benchmarks.

Ademais das probas de rendemento, observe o comportamento da aplicación no seguimento durante a semana. Se os gráficos mostran que a túa aplicación está a consumir menos recursos dos que solicitaches, podes reducir a cantidade de CPU ou memoria solicitada.

Por exemplo, vexa isto Panel de control Grafana. Mostra a diferenza entre os recursos solicitados ou o límite de recursos e o uso actual dos recursos.

Conclusión

A solicitude de recursos e o límite axudan a manter o clúster de Kubernetes saudable. A configuración adecuada dos límites minimiza os custos e mantén as aplicacións en funcionamento en todo momento.

En resumo, hai que ter en conta algunhas cousas:

Recursos solicitados: unha configuración que se ten en conta no momento do inicio (cando Kubernetes planea aloxar a aplicación). Pola contra, limitar os recursos é importante no tempo de execución, cando a aplicación xa se está a executar no host.
En comparación coa memoria, a CPU é un recurso regulado. En caso de falta de CPU, o seu Pod non se apagará, o mecanismo de aceleración activarase.
Os recursos solicitados e o límite de recursos non son valores mínimos e máximos! Ao especificar os recursos a solicitar, garante que a aplicación funciona sen problemas.
É unha boa práctica establecer a solicitude de memoria igual ao límite de memoria.
Instalación ben solicitada CPU <=1se a aplicación non realiza cálculos complexos.
Se solicita máis recursos dos que ten un nodo, o Pod nunca se programará para ese nodo.
Use probas de carga e seguimento para determinar a cantidade correcta de recursos/límites de recursos solicitados.

Espero que este artigo che axude a comprender o concepto básico de limitación de recursos. E podes aplicar estes coñecementos no teu traballo.

Boa sorte!

Que máis ler:

Fonte: www.habr.com

Como acceder aos recursos do pod de Kubernetes