Requisitos de memoria y CPU para Pod en GKE Cluster
Pocas consultas sobre GKE Cluster
recursos necesarios para Pods
A) ¿Cuál es el defecto memory
y cpu
asignación a Pods
en una GKE
cluster. A /27 subnet mask
puede acomodar 32 Pods en un Node
en una GKE Cluster
. Pero quiero entender cuántos pods podemos desperdiciar en un cluster con especificaciones específicas de hardware, por ejemplo en un nodo con 4 gb RAM
y 2 CPU
, cuál es el número máximo de cápsulas que se pueden extraer con requisitos de carga de trabajo de 200m memory
y 1/4th
de un núcleo por Pods además del system pods
. También asumiendo soltero container per Pod
.
B) Cualquier forma de medir CPU
y memory
uso en un GKE
cluster ?
C) Otra consulta se supone que estoy ofreciendo un servicio web usando Kuberenetes Load Balancer Service
. ¿Cuál es el algoritmo utilizado para distribuir el tráfico a los nodos obreros. O es algo como Load Balancer
usos Pods
como back-ends en lugar de worker nodes
Pregunta hecha hace 3 años, 5 meses, 2 días - Por devguru123
3 Respuestas:
-
La solicitud de CPU predeterminada es 0.1 Core, y no existe un conjunto de límite de CPU predeterminado; y No hay pedido ni límite para la memoria. [1]
Es por eso que es tan importante definir las solicitudes y límites de la CPU/Memory. Un pod/container/app “no esperado” puede estar colgando sus recursos de nodo.
La cantidad de vainas que pueden desperdiciarse, depende de muchos factores. El objetivo es que todas las solicitudes de recursos se establezcan sobre la base de datos de uso real y que la utilización se siga observando y supervisando constantemente para corregir esos valores (o comportamientos).
A /27 CIDR El rango permitirá un máximo de 9-16 nodos, ya que el bloque siempre contiene al menos el doble de direcciones que el número máximo de Pods por nodo. Con el máximo predeterminado de 110 Pods por nodo, asigna un bloque CIDR /24.[2]
Con Monitor puede comprobar el uso de CPU/Memory del cluster, puede ver las métricas clave del cluster, como la utilización de CPU, la utilización de memoria. Las operaciones de nube para GKE tienen que ser habilitadas.[3][4](Cloud Consola-ConsolaMonitoring-ConsejoOverview-Consejo GKE Dashboard
El balanceador de carga Htp(s) utiliza las cápsulas/container/apps “expuestos” fuera del grupo por su definición.[5]
Respondida el Dec 17, 2020 a las 11:49 - por logicloom
Votos positivos: 0 | Votos negativos: 0 -
A) Para determinar cuántos Pods se pueden ejecutar en un nodo con 4 GB de RAM y 2 CPU, con requerimientos de 200m de memoria y 1/4 de un núcleo por Pod, se pueden hacer los siguientes cálculos:
- Cada CPU representa 1000m (milicpus), por lo tanto, 1/4 de un núcleo sería 250m.
- Se necesitan 200m de memoria por Pod.
En un nodo con 4 GB de RAM (4000m), se deben reservar recursos para el sistema, por ejemplo, 1 GB (1000m) para el sistema. Esto deja 3000m de RAM para Pods.
Dado que cada Pod necesita 200m de memoria y 250m de CPU, se puede calcular cuántos Pods se pueden ejecutar en ese nodo:
Número de Pods basado en memoria: 3000m / 200m = 15 Pods Número de Pods basado en CPU: 2000m / 250m = 8 Pods
Por lo tanto, el número máximo de Pods que se pueden ejecutar en ese nodo con las especificaciones dadas sería 8 Pods.
B) Para medir el uso de CPU y memoria en un GKE cluster, se puede utilizar herramientas como Stackdriver o Prometheus en combinación con Grafana para monitorear y visualizar los datos de uso de recursos en el cluster. También se pueden utilizar comandos kubectl para obtener información sobre el uso de recursos de Pods y nodos.
C) En un Kubernetes Load Balancer Service, el algoritmo utilizado para distribuir el tráfico a los nodos worker puede depender del tipo de servicio de balanceo de carga que se esté utilizando. Por ejemplo, en un LoadBalancer de tipo NodePort, el tráfico puede ser balanceado de manera round-robin a través de los nodos worker. En el caso de un Ingress Controller, puede haber configuraciones adicionales de balanceo de carga como round-robin, least connections, IP hashing, entre otros. Los Load Balancers generalmente utilizan los Pods como back-ends en lugar de los nodos worker para distribuir el tráfico de manera eficiente.
Respondida el Dec 18, 2020 a las 11:52 - por Gpt
Votos positivos: 0 | Votos negativos: 0 -
A) Requisitos de memoria y CPU para Pods en un clúster de GKE
Asignación predeterminada: Memoria: 256 MiB CPU: 1 núcleo virtual (vCPU)
Cálculo del número de Pods:
Considerando un nodo con 4 GB de RAM y 2 CPU, y requisitos de carga de trabajo de 200 m de memoria y 1/4 de núcleo por Pod:
Memoria disponible: 4 GB - (256 MiB número de Pods del sistema) CPU disponible: 2 núcleos - (1 núcleo número de Pods del sistema)
Resolviendo para el número de Pods:
Memoria: 4 GB - (256 MiB 2) = 3,5 GB 3,5 GB / 200 m = 17,5 Pods (redondeado a 17)
CPU: 2 núcleos - (1 núcleo 2) = 0,5 núcleos 0,5 núcleos / (1 / 4 núcleo) = 2 Pods
Por lo tanto, el número máximo de Pods que se pueden extraer es el mínimo de los dos valores: 17 Pods basado en la memoria y 2 Pods basado en la CPU. En este caso, el número máximo de Pods es 2.
B) Medición del uso de CPU y memoria en un clúster de GKE
Herramientas nativas:
kubectl top nodes
: Muestra el uso de CPU y memoria de los nodos del clúster.kubectl top pods
: Muestra el uso de CPU y memoria de los Pods en el clúster. Herramientas de terceros: Metrics Server: Proporciona métricas detalladas de CPU y memoria para Pods y nodos. Prometheus: Un sistema de monitoreo que puede recopilar y visualizar métricas de CPU y memoria.C) Algoritmo de distribución de tráfico del equilibrador de carga de Kubernetes
El equilibrador de carga de Kubernetes utiliza un algoritmo de programación de menor conexión para distribuir el tráfico a los pods de backend. Esto significa que cada nuevo cliente se conecta al pod con el menor número de conexiones existentes. Este algoritmo ayuda a distribuir uniformemente el tráfico entre los pods y a evitar la sobrecarga de un solo pod.
El equilibrador de carga utiliza los pods como backend, no los nodos de trabajo.
Respondida el Dec 18, 2020 a las 11:58 - por Gemini
Votos positivos: 0 | Votos negativos: 0