Нормально ли, чтобы подача боке на Кубернетес периодически перезапускалась? - PullRequest
Новая
       8

Нормально ли, чтобы подача боке на Кубернетес периодически перезапускалась?

0 голосов
/ 18 февраля 2020

У меня есть панель инструментов bokeh, поданная в контейнере docker, который работает на kubernetes. Я могу получить доступ к своей панели удаленно, без проблем. Но я заметил, что мой модуль, содержащий код подачи боке, многократно перезагружается, то есть 14 раз за последние 2 часа. Иногда статус возвращается как «CrashLoopBackOff», а иногда он «работает» нормально.

Мой вопрос: есть ли что-то в том, как работает сервис bokeh, который требует, чтобы kubernetes перезапускал его так часто? Это как-то связано с памятью (OOMKilled)?

Вот раздел моего модуля описания: 

Name:               bokeh-744d4bc9d-5pkzq
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               10.183.226.51/10.183.226.51
Start Time:         Tue, 18 Feb 2020 11:55:44 +0000
Labels:             name=bokeh
                    pod-template-hash=744d4bc9d
Annotations:        kubernetes.io/psp: xyz-privileged-psp
Status:             Running
IP:                 172.30.255.130
Controlled By:      ReplicaSet/bokeh-744d4bc9d
Containers:
  dashboard-application:
    Container ID:   containerd://16d10dc5dd89235b0xyz2b5b31f8e313f3f0bb7efe82a12e00c1f01708e2f894
    Image:          us.icr.io/oss-data-science-np-dal/bokeh:118
    Image ID:       us.icr.io/oss-data-science-np-dal/bokeh@sha256:037a5b52a6e7c792fdxy80b01e29772dbfc33b10e819774462bee650cf0da
    Port:           5006/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 18 Feb 2020 14:25:36 +0000
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Tue, 18 Feb 2020 14:15:26 +0000
      Finished:     Tue, 18 Feb 2020 14:23:54 +0000
    Ready:          True
    Restart Count:  17
    Limits:
      cpu:     800m
      memory:  600Mi
    Requests:
      cpu:        600m
      memory:     400Mi
    Liveness:     http-get http://:5006/ delay=10s timeout=1s period=10s #success=1 #failure=3
    Readiness:    http-get http://:5006/ delay=10s timeout=1s period=3s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-cjhfk (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-cjhfk:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-cjhfk
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 600s
                 node.kubernetes.io/unreachable:NoExecute for 600s
Events:
  Type     Reason     Age                    From                    Message
  ----     ------     ----                   ----                    -------
  Warning  Unhealthy  36m (x219 over 150m)   kubelet, 10.183.226.51  Liveness probe failed: Get http://172.30.255.130:5006/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Warning  BackOff    21m (x34 over 134m)    kubelet, 10.183.226.51  Back-off restarting failed container
  Warning  Unhealthy  10m (x72 over 150m)    kubelet, 10.183.226.51  Readiness probe failed: Get http://172.30.255.130:5006/RCA: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  6m4s (x957 over 150m)  kubelet, 10.183.226.51  Readiness probe failed: Get http://172.30.255.130:5006/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  68s (x23 over 147m)    kubelet, 10.183.226.51  Liveness probe failed: Get http://172.30.255.130:5006/RCA: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Я новичок в k8s, поэтому любую информацию, которую вы должны сэкономить этот вопрос будет высоко ценится!

Ответы [ 2 ]

2 голосов
/ 18 февраля 2020

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

Вы можете отредактировать код, чтобы использовать меньше оперативной памяти, если это возможно, или увеличить limits.memory.

Как правило, вы хотите иметь запросы = ограничения, кроме случаев, когда ваш модуль запускает какие-то тяжелые вещи в начале, а затем ничего не делает.

Возможно, вы захотите взять посмотрите официальную документацию .

2 голосов
/ 18 февраля 2020

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

Возможно, вам придется увеличить лимиты и запросы в вашем модуле c. Проверьте официальный сделать c здесь .

Другой способ взглянуть на это - попытаться оптимизировать ваш код, чтобы он не превышал объем памяти, указанный в пределах.

...