Автоматическое исцеление контейнера Docker подходит ли Kubernetes для одного случая? - PullRequest
0 голосов
/ 08 октября 2019

У меня есть один док-контейнер, на котором работает pyppeteer. У него утечка памяти, поэтому он остановится через 24 часа.

Мне нужна какая-то система автоматического исцеления, я думаю, что Kubernetes может это сделать. Нет нагрузки, только один экземпляр, один контейнер. Это подходит?

++++

Наконец, я выбрал docker-py, управляемый с помощью Containers.run, Containers.prune.

Это работает для меня.

Ответы [ 4 ]

1 голос
/ 08 октября 2019

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

Вы можете делать то, что хотите на k8s, ноэто излишне. Весь кластер k8s для одного контейнера мне не подходит.

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

0 голосов
/ 15 октября 2019

Можно использовать функцию автоматического лечения Kubernetes, не создавая полномасштабный кластер Kubernetes. Требуется только установить совместимые версии пакетов docker и kubelet. Также может быть полезно установить пакет kubeadm.

Kubelet является частью плоскости управления Kubernetes, которая заботится о поддержании Стручков в здоровом состоянии. Он запускается как служба systemd и создает статических модулей с использованием файлов манифеста YAML из /etc/kubernetes/manifests (расположение настраивается).

Все остальные способы устранения неполадок приложения можно выполнить с помощью обычных команд docker:

docker ps ...
docker inspect
docker logs ...
docker exec ...
docker attach ...
docker cp ...

A хороший пример этого подхода из официальной документации - запуск внешних экземпляров кластера etcd. (Примечание: часть конфигурации Kubelet может не работать должным образом с последними версиями Kubelet. Я подробно расскажу об этом ниже.)

Также Kubelet может позаботиться об использовании ресурсов модуля, применив limit часть спецификации стручка. Таким образом, вы можете установить предел памяти, и когда контейнер достигнет этого предела, Kubelet перезапустит его.

Kubelet может выполнить проверку работоспособности приложения в модуле, если в спецификации Pod включен раздел проверки жизнеспособности. Если вы можете создать команду для более точной проверки состояния вашего приложения, kubelet может перезапустить контейнер, когда команда вернет ненулевой код выхода несколько раз подряд (настраивается).

Если kubelet отказывается запускаться, вы можетепроверьте логи kubelet с помощью следующей команды:

journalctl -e -u kubelet

Kubelet может отказаться запускаться в основном из-за:

  • отсутствие начальной конфигурации kubelet. Его можно сгенерировать с помощью команды kubeadm: kubeadm init phase kubelet-start. (Вам также может понадобиться сгенерировать сертификат CA /etc/kubernetes/pki/ca.crt, упомянутый в конфигурации kubelet. Это можно сделать с помощью kubadm: kubeadm init phase certs ca)

  • различных группнастройки драйвера для докера и кублета. Kubelet отлично работает с драйверами cgroupsfs и systemd. Драйвер по умолчанию для докера - cgroupfs. Kubeamd также генерирует конфигурацию kubelet с драйвером cgroupsfs, поэтому просто убедитесь, что они совпадают. Драйвер cgroups Docker может быть указан в файле определения сервиса, например, /lib/systemd/system/docker.service или /usr/lib/systemd/system/docker.service:

    #add cgroups driver option to ExecStart:
    ExecStart=/usr/bin/dockerd \
          --exec-opt native.cgroupdriver=systemd   # or cgroupfs
    

Чтобы изменить драйвер cgroups для последней версии kubelet, необходимо указать конфигурацию kubeletфайл для службы, поскольку такие параметры командной строки устарели:

sed -i 's/ExecStart=\/usr\/bin\/kubelet/ExecStart=\/usr\/bin\/kubelet --config=\/var\/lib\/kubelet\/config.yaml/' /lib/systemd/system/kubelet.service

Затем измените строку cgroups в конфигурации kubelet. Еще пара вариантов также требует изменений. Вот конфигурация kubelet, которую я использовал для той же цели:

address: 127.0.0.1                           # changed, was 0.0.0.0
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 2m0s
    enabled: false                           # changed, was true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt  # kubeadm init phase certs ca
authorization:
  mode: AlwaysAllow                          # changed, was Webhook
  webhook:
    cacheAuthorizedTTL: 5m0s
    cacheUnauthorizedTTL: 30s
cgroupDriver: cgroupfs                       # could be changed to systemd or left as is, as docker default driver is cgroupfs
cgroupsPerQOS: true
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
configMapAndSecretChangeDetectionStrategy: Watch
containerLogMaxFiles: 5
containerLogMaxSize: 10Mi
contentType: application/vnd.kubernetes.protobuf
cpuCFSQuota: true
cpuCFSQuotaPeriod: 100ms
cpuManagerPolicy: none
cpuManagerReconcilePeriod: 10s
enableControllerAttachDetach: true
enableDebuggingHandlers: true
enforceNodeAllocatable:
- pods
eventBurst: 10
eventRecordQPS: 5
evictionHard:
  imagefs.available: 15%
  memory.available: 100Mi
  nodefs.available: 10%
  nodefs.inodesFree: 5%
evictionPressureTransitionPeriod: 5m0s
failSwapOn: true
fileCheckFrequency: 20s
hairpinMode: promiscuous-bridge
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 20s
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80
imageMinimumGCAge: 2m0s
iptablesDropBit: 15
iptablesMasqueradeBit: 14
kind: KubeletConfiguration
kubeAPIBurst: 10
kubeAPIQPS: 5
makeIPTablesUtilChains: true
maxOpenFiles: 1000000
maxPods: 110
nodeLeaseDurationSeconds: 40
nodeStatusReportFrequency: 1m0s
nodeStatusUpdateFrequency: 10s
oomScoreAdj: -999
podPidsLimit: -1
port: 10250
registryBurst: 10
registryPullQPS: 5
resolvConf: /etc/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 2m0s
serializeImagePulls: true
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 4h0m0s
syncFrequency: 1m0s
volumeStatsAggPeriod: 1m0s

Перезапустите сервисы docker / kubelet:

systemctl daemon-reload
systemctl restart docker
systemctl restart kubelet
0 голосов
/ 08 октября 2019

Я не работал с Puppeteer, но после короткого исследования обнаружил this :

По умолчанию Docker запускает контейнер с / dev / shm общим пространством памяти 64 МБ. Это обычно слишком мало для Chrome и приведет к сбою Chrome при рендеринге больших страниц. Чтобы исправить, запустите контейнер с докером, запустите --shm-size = 1gb, чтобы увеличить размер / dev / shm. Начиная с Chrome 65, в этом больше нет необходимости. Вместо этого запустите браузер с флагом --disable-dev-shm-using:

const browser = await puppeteer.launch({
  args: ['--disable-dev-shm-usage']
});

Это позволит записывать файлы общей памяти в / tmp вместо /dev/shm.

Надеюсь, эта помощь.

0 голосов
/ 08 октября 2019

Есть несколько вариантов для вашего варианта использования, один из которых - запуск kubernetes. Но вы должны учитывать издержки на ресурсы и затраты на обслуживание при запуске kubernetes только для одного контейнера.

Я предлагаю вам изучить возможность перезапуска контейнера systemd в случае его сбоя или простого использования самого докера: с --restart=always parmeter демон docker обеспечивает работу контейнера. Примечание. Даже после перезапуска системный докер обеспечит перезапуск контейнера в этом случае. Так что --restart=on-failure может быть лучшим вариантом.

См. Эту страницу для получения дополнительной информации: https://docs.docker.com/config/containers/start-containers-automatically/#use-a-restart-policy

...