Перезапуск Kubernetes POD - PullRequest
       2

Перезапуск Kubernetes POD

3 голосов
/ 18 января 2020

Я использую кластер GKE с пулом из двух узлов.

Пул 1-го узла: 1 узел (без автоматического масштабирования) (4 vCPU, 16 ГБ ОЗУ)

Пул 2-го узла: 1 узел (Автоматическое масштабирование до 2 узлов) (1 vCPU, 3,75 ГБ ОЗУ)

здесь: верхний узел kubectl

enter image description here

мы запустили кластер с одним узлом, на котором работают Elasticsearch, Redis, RabbitMQ и все микросервисы на одном узле. мы не можем добавить больше узлов в пул 1-го узла, так как это приведет к потере ресурсов. 1-й узел может удовлетворить все потребности в ресурсах.

Нам грозит перезапуск POD только для одного микросервиса.

enter image description here

только основной модуль службы перезапуск. при попытке describe pod это ERROR 137 terminated.

В графе дисков стека GKE Memory и CPU не достигает предела.

Все модули в использовании кластера

enter image description here

В журнале кластера я обнаружил это предупреждение:

0/3 nodes are available: 3 Insufficient CPU. 

, но здесь это всего 3 узла, общий процессор около 6 vCPU, что более чем достаточно .

Также эта ошибка

Memory cgroup out of memory: Kill process 3383411 (python3) score 2046 or sacrifice child Killed process 3384902 (python3) total-vm:14356kB, anon-rss:5688kB, file-rss:4572kB, shmem-rss:0kB

РЕДАКТИРОВАТЬ: 1

Name:           test-core-7fc8bbcb4c-vrbtw
Namespace:      default
Priority:       0
Node:           gke-test-cluster-highmem-pool-gen2-f2743e02-msv2/10.128.0.7
Start Time:     Fri, 17 Jan 2020 19:59:54 +0530
Labels:         app=test-core
                pod-template-hash=7fc8bbcb4c
                tier=frontend
Annotations:    <none>
Status:         Running
IP:             10.40.0.41
IPs:            <none>
Controlled By:  ReplicaSet/test-core-7fc8bbcb4c
Containers:
  test-core:
    Container ID:   docker://0cc49c15ed852e99361590ee421a9193e10e7740b7373450174f549e9ba1d7b5
    Image:          gcr.io/test-production/core/production:fc30db4
    Image ID:       docker-pullable://gcr.io/test-production/core/production@sha256:b5dsd03b57sdfsa6035ff5ba9735984c3aa714bb4c9bb92f998ce0392ae31d055fe
    Ports:          9595/TCP, 443/TCP
    Host Ports:     0/TCP, 0/TCP
    State:          Running
      Started:      Sun, 19 Jan 2020 14:54:52 +0530
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Sun, 19 Jan 2020 07:36:42 +0530
      Finished:     Sun, 19 Jan 2020 14:54:51 +0530
    Ready:          True
    Restart Count:  7
    Limits:
      cpu:     990m
      memory:  1Gi
    Requests:
      cpu:      200m
      memory:   128Mi
    Liveness:   http-get http://:9595/k8/liveness delay=25s timeout=5s period=5s #success=1 #failure=30
    Readiness:  http-get http://:9595/k8/readiness delay=25s timeout=8s period=5s #success=1 #failure=30
    Environment Variables from:
      test-secret             Secret     Optional: false
      core-staging-configmap  ConfigMap  Optional: false
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-hcz6d:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-hcz6d
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <none>

Пожалуйста, помогите. Заранее благодарю.

1 Ответ

3 голосов
/ 19 января 2020

Приложение, запущенное в модуле, может потреблять больше памяти, чем указанные ограничения. Вы можете docker exe c / kubectl exe c в контейнер и контролировать приложения, используя top. Но с точки зрения управления всем кластером, мы делаем это с помощью cadvisor (который является частью Kubelet) + Heapster. Но теперь Heapster заменен сервером kube-metri c (https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring)

...