Celery: [K8S]セロリビートとワーカーのためのlivenessProbeとreadinessProbe

Celeryには、使用できる監視APIがあります。
Celeryワーカーがハートビートを送信する場合、ポッドはライブと見なされます。
ワーカーがworker-onlineイベントを送信した場合、ポッドは準備ができていると見なす必要があり

特定の問題や機能のリクエストがある場合は、別の問題を開いてください。

これは機能しますか？

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'は、準備チェックに十分であり、1つのノードのみを検証します。

一部のアプリでは、このコマンドの実行にフルCPUを使用すると数秒かかる場合があり、kubernetesのデフォルトでは10秒ごとに実行されることに注意してください。

したがって、periodSecondsを高くする方がはるかに安全です（300に設定されています）。

@redbaronそのコマンドはあなたのために働きましたか？ それが機能する場合、活気と準備の確率の設定は何ですか？

何らかの理由で、この準備プローブは私たちにとって満足のいくものではありません。 検査は、クラスターに負荷をかけずに非決定論的に応答します。 次のような形式を実行します。

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

また、通常のping時間（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ます。 準備プローブなしで、セロリを開始せず、それを知らなかった悪いコードを展開しました。

私の解決策は次のとおりです。

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

知っておくと良い

負荷が重いと、ジョブが正常に処理され、バックログがない場合でも、pingが一度に数分間ハングすることがわかったため、セロリ検査をリッピングして活性プローブからpingを実行することになりました。 イベントレットの使用と関係があると感じていますが、引き続き調査を続けています。

@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活性プローブを取り除きました。 私の腸はそれがイベントレットと関係があると私に言っていますが、私たちはそれを理解することを優先していません。

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を参照して

pingの検査のCPU使用率を減らす方法を見つけたと思います。

celery -b amqp：// user：pass @ rabitmq ：5672 / vhost pingを検査します

-A path.to.celeryを使用してセロリ構成をロードしないことは、CPUの使用に確かに役立ちました。
誰かが確認できますか。

pingの検査のCPU使用率を減らす方法を見つけたと思います。

celery -b amqp：// user：pass @ rabitmq ：5672 / vhost pingを検査します

-A path.to.celeryを使用してセロリ構成をロードしないことは、CPUの使用に確かに役立ちました。
誰かが確認できますか。

いいね！ アプリをロードした場合よりもはるかに優れています。
ただし、Pythonプロセスの開始+セロリのインポートには依然として大きなオーバーヘッドがあります。 私はまだ高い期間をお勧めします。

こんにちは、
celery inspect ping -A app.tasks -d celery @ $ HOSTNAMEは、「エラー：ブロードキャストはトランスポート 'sqs'でサポートされていません」と表示します。
ブローカーとしてSQSを使用しているので、これは「inspect」/「status」コマンドがSQSで機能しないことを意味しますか？

大規模な場合、すべてのリモートコントロール機能により、 kombu.pidboxキーのコマンドが設定されているためにRedisインスタンスがCPUで急上昇しているため、ping、ステータス、または検査をそのまま使用することはできません。すべてリモートコントロールを使用し、本番ユースケースでリモートコントロールを無効にしようとしています。

専用のヘルスチェックキューを用意するのが正しい方法のように思えますが、まったくわかりません

ヘルスチェックをテストするためのリモートコントロールを伴わない他の方向性を持っている人はいますか？

RabbitMQエビクションポリシー（キューは自動的に削除されます）を備えた専用のヘルスチェックキューをしばらくの間正常に使用しており、ソリューションに満足しています。 これは主に、このチェックが実際にワーカーがタスクを処理して終了することをチェックしているためです。 それを導入して以来、立ち往生している労働者の問題はもうありませんでした。

@bartoszhernasはそのためのコードを共有する気ですか？ あなたはビートを介してこれらをキューに入れ、労働者がそれを拾うよりも？

コード+活性プローブセクションを見たい

こんにちは、コードは本当に簡単です：

Kubernetesでは、POD_NAMEに基づいてキュー名を指定し、それをライブチェックスクリプトに渡します。

        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を展開しないため、bash -cを使用する必要があります）

次に、celery_liveness_probe.pyは、Celeryを使用できるようにDjangoを設定し、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を作成して、キューを毎回クリアすることです。