Как определить лимиты ресурсов и рассчитать потребление при развертывании приложений в Kubernetes?

Question

Я пытаюсь развернуть простой ансамбль zookeeper, следуя руководству официального сайта Kubernetes . В руководстве указано, что мне нужен

кластер как минимум с четырьмя узлами, и каждый узел требует как минимум 2 ЦП и 4 ГиБ памяти.

Я проигнорировал этот факт и создал кластер с 3 узлами n1-standard-1 (1 vCPU, 3,73 ГБ памяти) Когда я попытался применить файл .yaml

apiVersion: v1
kind: Service
metadata:
  name: zk-hs
  labels:
    app: zk
spec:
  ports:
    - port: 2888
      name: server
    - port: 3888
      name: leader-election
  clusterIP: None
  selector:
    app: zk
---
apiVersion: v1
kind: Service
metadata:
  name: zk-cs
  labels:
    app: zk
spec:
  ports:
    - port: 2181
      name: client
  selector:
    app: zk
---
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  selector:
    matchLabels:
      app: zk
  maxUnavailable: 1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: zk
spec:
  selector:
    matchLabels:
      app: zk
  serviceName: zk-hs
  replicas: 3
  updateStrategy:
    type: RollingUpdate
  podManagementPolicy: OrderedReady
  template:
    metadata:
      labels:
        app: zk
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                      - zk
              topologyKey: "kubernetes.io/hostname"
      containers:
        - name: kubernetes-zookeeper
          imagePullPolicy: Always
          image: "k8s.gcr.io/kubernetes-zookeeper:1.0-3.4.10"
          resources:
            requests:
              memory: "1Gi"
              cpu: "0.5"
          ports:
            - containerPort: 2181
              name: client
            - containerPort: 2888
              name: server
            - containerPort: 3888
              name: leader-election
          command:
            - sh
            - -c
            - "start-zookeeper \
          --servers=3 \
          --data_dir=/var/lib/zookeeper/data \
          --data_log_dir=/var/lib/zookeeper/data/log \
          --conf_dir=/opt/zookeeper/conf \
          --client_port=2181 \
          --election_port=3888 \
          --server_port=2888 \
          --tick_time=2000 \
          --init_limit=10 \
          --sync_limit=5 \
          --heap=512M \
          --max_client_cnxns=60 \
          --snap_retain_count=3 \
          --purge_interval=12 \
          --max_session_timeout=40000 \
          --min_session_timeout=4000 \
          --log_level=INFO"
          readinessProbe:
            exec:
              command:
                - sh
                - -c
                - "zookeeper-ready 2181"
            initialDelaySeconds: 10
            timeoutSeconds: 5
          livenessProbe:
            exec:
              command:
                - sh
                - -c
                - "zookeeper-ready 2181"
            initialDelaySeconds: 10
            timeoutSeconds: 5
          volumeMounts:
            - name: datadir
              mountPath: /var/lib/zookeeper
      securityContext:
        runAsUser: 1000
        fsGroup: 1000
  volumeClaimTemplates:
    - metadata:
        name: datadir
      spec:
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: 10Gi

И, конечно же, я получил ошибку PodUnschedulable

В этом файле я в облаке не нашел ничего, что говорило бы, что мне нужен кластер из 4 узлов, с 2 процессорами и 4G Ram. Итак:

• Что определяет, сколько ресурсов требуется моему развертыванию?
• Как заранее понять / рассчитать требуемые ресурсы приложений и их соответствующих развертываний?
• Zookeeper работает на 2 ГБ ОЗУ в соответствии с требованиями, но это только рекомендуемая конфигурация.

Answer 1

По умолчанию узлы kubernetes не будут пустыми. Вместо этого у него есть запущенные процессы еще до запуска вашей рабочей нагрузки приложений:

• kubelet выполняется (в каждом узле)
• kube-proxy работает как демон-набор (на каждом узле)
• среда выполнения контейнера (Docker) работает на каждом узле
• может быть запущен другой набор-демон (например, aws -узел DS в случае EKS ..).

Мы здесь обсуждаем рабочие узлы, а не мастера.

Итак, представьте себе все это, в конечном итоге вы выберете подходящие ресурсы для каждого узла.

Не все узлы должны быть одинакового размера. Однако вы решаете, какой размер вам нужен в соответствии с типом ваших приложений:

• Если ваши приложения потребляют память больше, чем процессоры (например, Java Приложения), вам нужно будет выбрать Node of [2CPU, 8GB] лучше, чем [4CPUs, 8GB] .

• Если ваши приложения потребляют CPU больше, чем память (например, рабочая нагрузка ML ), вам нужно будет выбрать противоположное; инстансы, оптимизированные для вычислений.

• Золотое правило ? состоит в том, чтобы вычислить полную емкость лучше, чем рассматривать индивидуальную емкость для каждого узла.

Это означает, что 3 больших узла могут быть лучше, чем 4 средних узлов с точки зрения стоимости, но также и с точки зрения наилучшего использования емкости.

введите описание изображения здесь

В заключение ресурс узла должен быть:

• не менее 2 ЦП
• не менее 4 ГБ памяти

В противном случае следует ожидать проблем с емкостью.

Теперь мы подошли к половине ответа: определите емкость кластера.

Вторая половина касается ответа о том, как назначить ресурсы для каждого приложения (модуля) .

Это попадает в другой вопрос; Сколько потребляет ваше приложение?

Чтобы ответить на этот вопрос, вам нужно контролировать свое приложение с помощью инструментов APM, таких как Prometheus + Grafana.

Как только вы получите представление о средних показателях потребления, самое время для установки ограничений ресурсов для вашего приложения (его подов).

Лимиты могут ограничивать приложение, поэтому вам необходимо настроить наряду с другими функциями для горизонтального автоматического -scaling:

• Запуск модулей внутри развертывания для управления репликами и развертыванием.
• Автоматическое масштабирование HPA или Horizontal Pod: которое отслеживает модули развертывания, а затем масштабирует их в соответствии с пороговыми значениями (ЦП, память)

В качестве заключения для этой части мы можем сказать:

- Измерение: начать измерение для идентификации resources.limits и resources.requests .

- Измерение: измерение после запуска приложения для повторного определения необходимых ресурсов.

- Измерение: Сохранить измерение

Answer 2

Раздел

resources в yaml развертывания определяет требования к ресурсам контейнера в модуле.

resources:
  requests:
    memory: "1Gi"
    cpu: "0.5"

requests означает, что узлу необходимо иметь более 1 ГБ памяти и 0,5 ЦП, доступных для одна из реплик модуля должна быть запланирована на этом узле.

Существует еще одна концепция limits, которая определяет максимальный ресурс, который модуль может потреблять до того, как он будет вытеснен из узла.

resources:
  requests:
    memory: "1Gi"
    cpu: "0.5"
  limits:
    memory: "2Gi"
    cpu: "2"

Несмотря на то, что у вас есть 3 узла, главный узел не расписан по умолчанию.

Вы можете понять доступность ресурсов узла, набрав kubectl describe nodename и проверив разделы Capacity и Allocatable.

Capacity:
  cpu:                4
  ephemeral-storage:  8065444Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             16424256Ki
  pods:               110
Allocatable:
  cpu:                4
  ephemeral-storage:  7433113179
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             16321856Ki
  pods:               110

Что касается расчета потребности в ресурсах (requests и limits) капсулы, серебряной пули нет. Это зависит от приложения и должно определяться и настраиваться путем его профилирования. Но рекомендуется определять requests и limits при развертывании модуля.