Q: Как настроить кластер kubernetes для лучшего распределения нагрузки на процессор?

Question

Один из моих кластеров Kubernetes (GKE) - это всего три узла, и часто один узел перегружен для ЦП. У меня есть около 32 развертываний, и у большинства есть 3 модуля. Когда один узел перегружен, я обычно вижу 1 модуль из 3, показывающий CrashLoop. В идеале вещи не будут терпеть крах, и ни один из моих узлов не будет использовать более 100%.

Чтобы решить эту проблему, я удаляю стручки, дренирую и извлекаю узел, или тяну узел, и вещи обычно возвращаются в нормальное состояние. Однако мне интересно, как другие решают эту проблему:

1. Нужна ли мне проверка здоровья?
2. Неправильные ли настройки моего ресурса (слишком низкие)?
3. Как правильно отладить это? Я использую kubectl top nodes, kubectl top pods и kubectl get pods -o wide, чтобы понять, что происходит.

Типичный перекос узла:

kubectl top nodes                                                                                                                                                                                                                                                                                                                                        
NAME                                             CPU(cores)   CPU%      MEMORY(bytes)   MEMORY%                                                                                                                                                                                                                                                                                                      
gke-staging-cluster-default-pool-386bd62d-bj36   481m         24%       4120Mi          38%                                                                                                                                                                                                                                                                                                          
gke-staging-cluster-default-pool-386bd62d-cl3p   716m         37%       6583Mi          62%       
gke-staging-cluster-default-pool-386bd62d-gms8   1999m        103%      6679Mi          63%       

Под ресурсы:

kubectl top pod | sort -nr -k2
hchchc-staging-deployment-669ff7477c-lcx5d                248m         47Mi                                                                                                                                                                                                                                                                                                                          
ggg-hc-demo-staging-deployment-77f68db7f8-nf9b5             248m         125Mi           
ggg-hc-demo-staging-deployment-77f68db7f8-c6jxd             247m         96Mi            
ggg-hc-demo-staging-deployment-77f68db7f8-l44vj             244m         196Mi           
athatha-staging-deployment-6dbdf7fb5d-h92h7                 244m         95Mi            
athatha-staging-deployment-6dbdf7fb5d-hqpm9                 243m         222Mi           
engine-cron-staging-deployment-77cfbfb948-9s9rv             142m         35Mi            
hchchc-twitter-staging-deployment-7846f845c6-g8wt4        59m          83Mi            
hchchc-worker-staging-deployment-7cbf995ddd-msrbt         51m          114Mi           
hchchc-twitter-staging-deployment-7846f845c6-brlbl        51m          94Mi            

Соотношение стручков и узлов:

kubectl get pods -o wide | grep Crash

hchchc-twitter-staging-deployment-7846f845c6-v8mgh        1/2       CrashLoopBackOff   17         1h    10.0.199.31   gke-staging-cluster-default-pool-386bd62d-gms8
hchchc-worker-staging-deployment-66d7b5d7f4-thxn6         1/2       CrashLoopBackOff   17         1h    10.0.199.31   gke-staging-cluster-default-pool-386bd62d-gms8
ggggg-worker-staging-deployment-76b84969d-hqqhb           1/2       CrashLoopBackOff   17         1h    10.0.199.31   gke-staging-cluster-default-pool-386bd62d-gms8
ggggg-worker-staging-deployment-76b84969d-t4xmb           1/2       CrashLoopBackOff   17         1h    10.0.199.31   gke-staging-cluster-default-pool-386bd62d-gms8
ggggg-worker-staging-deployment-76b84969d-zpkkf           1/2       CrashLoopBackOff   17         1h    10.0.199.31   gke-staging-cluster-default-pool-386bd62d-gms8

Answer 1

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

Пример антиаффинности:

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          topologyKey: kubernetes.io/hostname

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

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

Подробнее об антиаффинности можно узнать здесь: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/