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