Ключевые требования

Описание 

Приложение имеет Readiness probe

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

Readiness probe позволяет проверить готово ли приложение принимать трафик. Например, наше приложение  должно как-то обрабатывать данные в БД. Но по какой-то причине база данных не отвечает конкретному  инстансу приложения. Получается, что приложение не может правильно работать. В этом случае мы  настраиваем Readiness Probe так, чтобы оно проверяло коннект с БД. Если проверка завершится с ошибкой, то  Kubernetes не будет перенаправлять трафик на этот под, при этом под не будет перезапущен. Главное отличие  от Liveness Probe в том, что Readiness Probe не перезапускает приложение, а просто ждет, когда проверка  снова будет проходить успешно. 

Если вы не установите Readiness probe, то kubelet будет предполагать, что приложение готово к  приему трафика, как только контейнер запустится.

При использовании universalChart определите в своем values.yaml  блок с секцией readinessProbe. Пример: 

readinessProbe: 

 httpGet: 

 path: /sys/health/readiness 

 scheme: HTTP 

 port: 8080 

 periodSeconds: 10 

 timeoutSeconds: 2 

 successThreshold: 2 

 failureThreshold: 4 

Приложение имеет Liveness probe

Endpoint, который используется для проверки живучести приложения. 

Liveness probe позволяет перезапустить зависшее приложение. Бывают ситуации, когда приложение зависает и  не отвечает на запросы, тогда его нужно перезапустить. В этом помогает Liveness Probe: если проверка  завершится с ошибкой, то Kubernetes перезапустит этот под. 

Вам не следует использовать Liveness probe для обработки Fatal Errors в вашем приложении и  запрашивать у Kubernetes перезапуск приложения. 

Вместо этого вы должны позволить приложению завершить работу. 

Liveness probe следует использовать в качестве механизма восстановления только в том случае,  если процесс не отвечает.

При использовании universalChart определите в своем values.yaml  блок с секцией livenessProbe. Пример: 

livenessProbe: 

 httpGet: 

 path: /sys/health/liveness 

 scheme: HTTP 

 port: 8080 

 periodSeconds: 10 

 timeoutSeconds: 2 

 successThreshold: 1 

 failureThreshold: 3 

Приложение умеет аварийно завершать работу при Fatal Error

Если приложение выдает неустранимую ошибку, вы должны позволить ему завершиться сбоем. Примеры неустранимых ошибок: 

- uncaught exception 

- опечатка в коде (для динамических ЯП) 

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

Пожалуйста, обратите внимание, что вы не должны сигнализировать о сбое проверке жизнеспособности (Liveness probe). 

Вместо этого вы должны немедленно выйти из процесса и позволить kubelet перезапустить  контейнер.

Endpoint и параметры для проверок Liveness и Readiness не должны быть идентичными!

Когда проверки жизнеспособности (Liveness probe) и готовности (Readiness probe) указывают на один и тот же Endpoint, эффект от проверок объединяется. 

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

Readiness probe и зависимости от смежных сервисов (служб)

Желательно, чтобы проверка Readiness не включала зависимости от таких служб, как:  

БД 

Миграции в БД 

APIs 

Прочие сервисы и службы 

Так как это может привести к каскадному сбою (Cascading Failures) и приложение будет выведено из раздачи, т. е. на него не будет поступать трафик. 

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

В целом, если ваше приложение технически готово и работает, даже если оно не может функционировать  идеально, то Readiness Probe (проверка готовности) не должна быть провалена. Хорошим компромиссом  является реализация «Degraded mode». Например, если нет доступа к базе данных, то можно отвечать на  

запросы (для чтения), которые могут храниться в локальном кэше, и возвращать код 503 (service unavailable) для запросов на запись в БД.

Приложение умеет повторять попытку подключения к зависимым службам

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

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

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

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

Приложение умеет корректно обрабатывать SIGTERM и завершать свою работу

Может пройти некоторое время, прежде чем такой компонент, как kube-proxy или Ingress контроллер, будет  уведомлен об изменениях в Endpoints. 

Таким образом, трафик все еще может поступать в приложение несмотря на то, что Pod помечен как Terminating. 

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

После этого приложение должно корректно завершить свою работу.

Приложение не должно обрабатывать новые запросы в течение Graceful shutdown периода

Возможно, вы захотите рассмотреть возможность использования событий жизненного цикла контейнера (container lifecycle events), таких как preStop hook, для настройки того, что будет происходить перед удалением Pod'а. 

При использовании universalChart определите в своем values.yaml  блок с секцией lifecycleHooks: Пример: 

lifecycleHooks: 

 preStop: 

 exec: 

 command: [ "sh", "-c", "sleep 30" ]

При написании Docker file используйте инструкцию CMD (exec form) для корректной обработки SIGTERM сигнализации

Командная оболочка (Shell), поставляемая по умолчанию с Alpine Linux, не передает сигнализацию дочерним  процессам, поэтому необходимо использовать инструкцию CMD в executable form. 

CMD [ "java", "-jar", "app.jar" ] 

Вы можете быть уведомлены в логах о том, что Pod будет терминирован, перехватив SIGTERM сигнализацию в  вашем приложении. 

Также следует обратить внимание на пересылку SIGTERM нужному процессу в вашем контейнере.

Закрывайте все бездействующие (idle) keep alived сокеты

Если приложение не закрывает TCP-соединение при обращении к другому сервису (например, используя TCP  keep-alive или пул подключений), то оно подключится только к одному Pod'у и не будет использовать другие  Pod'ы в этом сервисе. 

Но что произойдет когда Pod будет удален? 

В идеале запрос должен быть отправлен в другой Pod. 

Но так как открыто долгоживущее (long-live) соединение, то приложение продолжит использовать его. С другой стороны, вы не должны резко завершать долгоживущие (long-live) соединения. Вместо этого вы должны завершить их работу перед выключением приложения.

Всегда запускать более одной реплики вашего приложения в продуктивном окружении

Запуск более одного экземпляра ваших Pod'ов гарантирует, что удаление Pod'а не приведет к простою. 

Также для распределения реплик по зонам доступности (в кластере Kubernetes) используйте опцию zoneAwareS etup: true, которая обеспечивает включение TopologySpreadConstraints в universalChart. 

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

Избегайте размещения Pod-ов на одном узле

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

Рассмотрим следующий сценарий: у вас есть 11 реплик на одном узле кластера. 

Если узел становится недоступным, 11 реплик теряются, и у вас возникает время простоя. 

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

Всегда устанавливайте Pod Disruption Budgets (PDB), если запускаете более одной реплики вашего приложения в продуктивном окружении

Pod Disruption Budget (PDB) — это минимальное количество реплик приложения, которые Kubernetes  постарается сохранить для стабильной работы. PDB защищает приложение от некоторых, но не всех типов  простоев. Существует два типа причин простоев: 

Непреднамеренный сбой происходит случайно из-за ошибки ПО или сбоя оборудования. Например, выход  узла из строя, недоступность сети или Kernel Panic в ядре. 

Добровольное прерывание происходит осознанно по инициативе администратора или разработчика.  Например, Rolling Update для выпуска новой версии приложения или отключение узла для  техобслуживания/обновления. Когда узел кластера выводится на техобслуживание/обновление, все  модули на этом узле удаляются и переносятся на другой. 

Но что, если ваше приложение находится под высокой нагрузкой и вы не можете потерять более 50% своих  Pod'ов? 

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

Чтобы защитить ваши развертывания (Deployments) от непредвиденных событий, которые могут привести к  одновременному отключению нескольких модулей, вы можете определить бюджет для сбоев модулей (Pod  Disruption Budgets). 

Представьте, что вы говорите: "Kubernetes, пожалуйста, убедитесь, что для моего приложения всегда запущено  по крайней мере 5 модулей". 

В universalChart при развертывании приложения от 2-ух реплик - PDB включается автоматически. Вам также необходимо определить (в своем values.yaml файле) параметры для PDB. 

Пример: 

pdb: 

 matchLabel: <label_for_matching_pods> 

 minAvailable: 50%

Всегда задавайте requests и limits ( CPU и Memory ) для вашего приложения

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

Планировщик Kubernetes использует их в качестве одной из метрик, чтобы решить, на какой узел лучше всего  разместить ваш Pod. 

Неограниченное количество модулей (без ограничений по ресурсам) может привести к чрезмерному  использованию ресурсов и потенциальному сбою узла (и kubelet). 

То же самое относится и к ограничениям процессора. 

Запросы (requests) — это ресурсы, которые контейнер гарантированно получит. То есть это своего рода  минимальные системные требования, которые нужны приложению для работы. Kubernetes всегда планирует  размещение подов на узлах так, чтобы обеспечить необходимые запросы для всех подов. 

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

Если под попытается превысить ресурс, Kubernetes поступит по-разному в зависимости от типа ресурса. 

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

RAM — несжимаемый ресурс, его невозможно ограничить. Ведь если приложению просто не выделить  запрашиваемую память, оно, скорее всего, перестанет нормально работать. Поэтому если под запросит  больше памяти, чем указано в ограничениях, Kubernetes перезапустит под. 

По умолчанию для всех продуктовых немспейсов используются LimitRanges. Если вы не задали  ресурсы для вашего контейнера, то будут использоваться дефолтовые параметры. Они имеют  следующие значения: 

   spec: 

    limits: 

    - default: 

        cpu: 250m 

        memory: 512Mi 

      defaultRequest: 

        cpu: 250m 

        memory: 512Mi 

      max: 

        cpu: "2" 

        memory: 16Gi 

      maxLimitRequestRatio: 

        cpu: "4" 

        memory: "2" 

      min: 

        cpu: 50m 

        memory: 64Mi 

      type: Container

При использовании universalChart определите в своем values.yaml блок с секцией resources, чтобы указать  необходимые ресурсы для вашего контейнера с приложением. 

Пример: 

resources: 

 limits: 

 cpu: 2 

 memory: 4Gi 

 requests: 

 cpu: 1 

 memory: 2Gi 

Установите значение cpu. requests : 1 или ниже (для приложений с низкой вычислительной нагрузкой)

Если у вас нет заданий с высокой вычислительной нагрузкой, рекомендуется установить cpu.requests : 1  или  ниже. 

Установите соответствующее качество обслуживания (QoS) для ваших модулей (Pod'ов)

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

Kubernetes ранжирует и выселяет модули в соответствии с четко определенной логикой.