Celery: [K8S] 셀러리 비트 및 워커를위한 livenessProbe 및 readinessProbe

Celery에는 사용할 수있는 모니터링 API 가 있습니다.
Celery 작업자가 하트 비트를 보내는 경우 포드는 라이브로 간주되어야합니다.
작업자가 작업자 온라인 이벤트를 보낸 경우 포드가 준비된 것으로 간주되어야합니다.

특정 문제 나 기능 요청이있는 경우 별도의 문제를여십시오.

작동할까요?

readinessProbe:
          exec:
            command:
            - "/bin/sh"
            - "-c"
            - "celery -A path.to.app status | grep -o ': OK'"
          initialDelaySeconds: 30
          periodSeconds: 10

@ 7wonders 먼저 셀러리 노드 이름을 추출해야합니다. 이 readinessProbe는 원하는 셀러리 인스턴스가 실패하면 실패합니다.

@thedrow 흠, 실제로 실제 노드가 실패해도 성공할 것이라고 생각하지만 다른 노드는 괜찮습니다.

처럼 보인다

/bin/sh -c 'exec celery -A path.to.app inspect ping -d celery@$HOSTNAME' 는 준비 상태 확인에 충분하며 하나의 노드 만 확인합니다.

일부 앱에서는 전체 CPU를 사용하여이 명령을 실행하는 데 몇 초가 걸릴 수 있으며 kubernetes 기본값은 10 초마다 실행하는 것입니다.

따라서 periodSeconds를 높게 설정하는 것이 훨씬 안전합니다 (우리는 300으로 설정 됨).

@redbaron 이 명령이 작동 했습니까? 작동한다면 활성 및 준비 가능성에 대한 설정은 무엇입니까?

어떤 이유로이 준비 상태 프로브는 우리에게 거의 만족스럽지 않습니다. 검사는 클러스터에 부하없이 비 결정적으로 응답합니다. 다음과 같은 형식을 실행합니다.

celery inspect ping -b " redis : // archii-redis-master : 6379"-d celery @ archii-task-crawl-integration-7d96d86b9d-jwtq7

그리고 정상적인 핑 시간 (10 초)을 사용하면 클러스터가 셀러리가 요구하는 CPU에 의해 완전히 종료됩니다.

~ 나는 이것을 30 초 간격으로 생동감있게 사용합니다 : sh -c celery -A path.to.app status | grep "${HOSTNAME}:.*OK" ~
나는 이것을 30 초 간격으로 생동감있게 사용한다 : sh -c celery -A path.to.app inspect ping --destination celery@${HOSTNAME}
추가 부하를 유발하지 않는 것 같고 100 명이 넘는 작업자를 운영하고 있습니다.

준비 상태 프로브는 필요하지 않으며 Celery는 서비스에 사용되지 않습니다. 롤링 배포에서 작업자 시작을 지연시키는 데 충분한 minReadySeconds: 10 를 설정했습니다.하지만 분명히 프로젝트의 Celery 시작 시간에 따라 다르므로 로그를 검토하고 적절하게 설정합니다.

준비 상태 프로브는 서비스에서 사용되지 않더라도 여전히 유용합니다. 특히 작업자 배포를 수행하고 배포가 성공했는지 확인하려면 일반적으로 kubectl rollout status deployment 합니다. readinessprobes없이 우리는 셀러리를 시작하지 않았고 그것을 알지 못하는 나쁜 코드를 배포했습니다.

내 솔루션은 다음과 같습니다.

readinessProbe:
  exec:
    command:
      [
        "/usr/local/bin/python",
        "-c",
        "\"import os;from celery.task.control import inspect;from <APP> import celery_app;exit(0 if os.environ['HOSTNAME'] in ','.join(inspect(app=celery_app).stats().keys()) else 1)\""
      ]

다른 사람들은 작동하지 않는 것 같습니다 🤷‍♂️

감사합니다 @yardensachs!
다른 솔루션의 문제점을 디버깅하는 데 많은 시간을 투자하십시오.
celery inspect ping 명령이 exit (0) 또는 그런 식으로 반환하지 않는 것 같습니다.

celery inspect ping 는 작동하지만 다음과 같이 환경 변수를 바꾸려면 bash 가 필요합니다.

        livenessProbe:
          exec:
            # bash is needed to replace the environment variable
            command: [
              "bash",
              "-c",
              "celery inspect ping -A apps -d celery@$HOSTNAME"
            ]
          initialDelaySeconds: 30  # startup takes some time
          periodSeconds: 60  # default is quite often and celery uses a lot cpu/ram then.
          timeoutSeconds: 10  # default is too low

~ 알아 둘만 한

작업이 잘 처리되고 백 로그가 없는데도 부하가 더 높으면 한 번에 몇 분 동안 핑이 중단된다는 사실을 발견했기 때문에 활성 상태 프로브에서 셀러리 검사 핑을 추출했습니다. eventlet을 사용하는 것과 관련이 있다고 생각하지만 계속 조사 중입니다.

@WillPlatnick Celery는 비동기식이므로 제어 코 루틴을위한 예약 된 용량이 있기 때문에 5.0에서는 발생하지 않습니다.

inspect ping 생성되지 않는 / 좀비 프로세스에 문제가 있습니다.

root      2296  0.0  0.0      0     0 ?        Z    16:04   0:00 [python] <defunct>
root      2323  0.0  0.0      0     0 ?        Z    16:05   0:00 [python] <defunct>
...

이 문제가 발생하는 다른 사람이 있습니까? 단일 프로세스 실행을 강제하기위한 --pool 인수가 없습니다.

celery inspect ping @WillPlatnick 대신 무엇을 사용하고 계십니까? 과부하 상태에서 프로브가 실패하는 것과 유사한 문제가 발생했습니다.

@mcyprian 우리는 활성 프로브를 제거했습니다. 내 직감은 eventlet과 관련이 있다고 말하지만 우리는 그것을 알아내는 것을 우선 순위로 두지 않았습니다.

Redis 브로커와 동일한 CPU 문제를 만납니다.

누구든지 해결책을 찾았습니까?
우리는 또한 컨테이너 이름을 기반으로 한 이름을 큐에서 "debug_task"로 예약하는 실험을했습니다. 문제는 현재 RabbitMQ에 많은 오래된 대기열이 있다는 것입니다.

사용에 유의하십시오

sh -c celery -A path.to.app status | grep "${HOSTNAME}:.*OK"

https://github.com/celery/celery/issues/4079#issuecomment -437415370에 제안 된대로 rabbitmq에 대한 대규모 오류 보고서가 발생합니다. https://github.com/celery/celery/issues/4355#issuecomment 참조 - 578786369

검사 핑의 CPU 사용량을 줄이는 방법을 찾은 것 같습니다.

celery -b amqp : // user : pass @ rabbitmq : 5672 / vhost ping 검사

-A path.to.celery를 사용하여 셀러리 구성을로드하지 않으면 확실히 CPU 사용에 도움이되었습니다.
누군가 확인할 수 있습니다.

검사 핑의 CPU 사용량을 줄이는 방법을 찾은 것 같습니다.

celery -b amqp : // user : pass @ rabbitmq : 5672 / vhost ping 검사

-A path.to.celery를 사용하여 셀러리 구성을로드하지 않으면 확실히 CPU 사용에 도움이되었습니다.
누군가 확인할 수 있습니다.

좋은! 로드 된 앱보다 훨씬 낫습니다.
그러나 우리는 여전히 셀러리 가져 오기를 시작하는 파이썬 프로세스의 엄청난 오버 헤드를 얻습니다. 나는 여전히 높은 기간을 권장합니다.

안녕하세요,
celery inspect ping -A app.tasks -d celery @ $ HOSTNAME은 "Error : Broadcast not supported by transport 'sqs'"를 제공합니다.
SQS를 브로커로 사용하고 있는데 'inspect'/ 'status'명령이 SQS에서 작동하지 않음을 의미합니까?

규모에 따라 모든 원격 제어 기능으로 인해 kombu.pidbox 키에 대한 명령 설정으로 인해 Redis 인스턴스가 CPU에서 급증하는 것으로 확인되었으므로 ping을 사용하거나 상태를 그대로 검사하거나 검사 할 수 없습니다. 모두 원격 제어를 사용하고 프로덕션 사용 사례를 위해 원격 제어를 비활성화하려고합니다.

전용 상태 확인 대기열을 갖는 것이 올바른 방법 인 것 같지만 전혀 확실하지 않습니다.

누구든지 건강 검사를 테스트하기 위해 원격 제어를 포함하지 않는 다른 방향이 있습니까?

우리는 RabbitMQ 제거 정책 (대기열이 자동으로 삭제됨)과 함께 전용 상태 확인 대기열을 얼마 동안 성공적으로 사용하고 있으며 솔루션에 만족합니다. 대부분이 검사는 실제로 작업자가 작업을 처리하고 완료하는지 확인하기 때문입니다. 우리가 그것을 도입 한 이후로 우리는 갇힌 노동자들에게 더 이상 문제가 없었습니다.

@bartoszhernas 마음에 몇 가지 코드를 공유합니까? 비트를 통해 대기열에 추가하고 작업자가 픽업하는 것보다?

코드 + 활성 프로브 섹션을보고 싶습니다.

안녕하세요, 코드는 정말 쉽습니다.

Kubernetes에서 POD_NAME을 기반으로 대기열 이름을 지정하고이를 livecheck 스크립트에 전달합니다.

        livenessProbe:
          initialDelaySeconds: 120
          periodSeconds: 70
          failureThreshold: 1
          exec:
            command:
            - bash 
            - "-c" 
            - |
              python celery_liveness_probe.py $LIVENESS_QUEUE_NAME
        env:
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name

        - name: LIVENESS_QUEUE_NAME
          value: queue-$(MY_POD_NAME)

(Kubernetes가 ENV를 직접 명령으로 전달하려고 할 때 ENV를 확장하지 않기 때문에 bash -c를 사용해야합니다)

그런 다음 celery_liveness_probe.py는 Django를 설정하여 Celery를 사용하고 POD 대기열에서 작업을 예약합니다.

# encoding: utf-8
from __future__ import absolute_import, unicode_literals

import os
import sys

if __name__ == "__main__":
    import django

    sys.path.append(os.path.join(os.path.dirname(__file__), '..', '..'))
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "ahoy.archive.settings")
    django.setup()
    from ahoy.archive.apps.eventbus.service import eventbus_service

    exit(0 if eventbus_service.health_check(sys.argv[1] if sys.argv and len(sys.argv) > 1 else None) else 1)

상태 확인 기능은 작업을 보내고 결과를 기다립니다.

    def health_check(self, queue_name: Optional[str] = None) -> bool:
        event = self.celery.send_task(
            AhoyEventBusTaskName.LIVENESS_PROBE,
            None,
            queue=queue_name or self.origin_queue,
            ignore_result=False,
            acks_late=True,
            retry=False,
            priority=255
        )

        try:
            is_success = event.get(timeout=10)
        except (celery.exceptions.TimeoutError, AttributeError):
            is_success = False

        return is_success

따라서 기본적으로 작업을 보내고 결과가 반환되면 작업자는 정상입니다. 작업자가 멈춘 경우 (여러 번 발생) 작업이 완료되지 않고 포드가 다시 시작되고 모든 것이 정상으로 돌아갑니다.

유일한주의 사항은 기존 대기열을 처리해야한다는 것입니다. RabbitMQ를 사용하면 간단합니다. 대기열에 만료 정책을 설정하기 만하면됩니다.
https://www.rabbitmq.com/ttl.html#queue -ttl

@bartoszhernas 코드를 공유

내 대기열이 동적이며 Redis를 사용하고 있다고 말씀하신 것처럼 Redis에서 대기열 이름 만료를 처리하는 방법을 찾아야합니다.

예, Redis의 BullMQ와 비슷한 문제가 있습니다. 내 생각은 매번 대기열을 지우는 Kubernetes 용 CronJob을 작성하는 것입니다.