0

次の deployment.yaml を使用して Celery Beat をセットアップしました。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: celery-beat
  labels:
    deployment: celery-beat
spec:
  replicas: 1
  minReadySeconds: 120
  selector:
    matchLabels:
      app: celery-beat
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 0 # Would rather have downtime than an additional instance in service?
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: celery-beat
    spec:
      containers:
        - name: celery-beat
          image: image_url
          command: ["/var/app/scripts/kube_worker_beat_start.sh"]
          imagePullPolicy: Always
          ports:
            - containerPort: 8000
              name: http-server
          livenessProbe: #From https://github.com/celery/celery/issues/4079#issuecomment-437415370
            exec:
              command:
                - /bin/sh
                - -c
                - celery -A app_name status | grep ".*OK"
            initialDelaySeconds: 3600 
            periodSeconds: 3600
          readinessProbe:
            exec:
              command:
                - /bin/sh
                - -c
                - celery -A app_name status | grep ".*OK"
            initialDelaySeconds: 60
            periodSeconds: 30 
          resources:
            limits:
              cpu: "0.5" #500mcores - only really required on install
            requests:
              cpu: "30m"

RollingUpdateCelery Beat では、実際には 2 つのインスタンスが必要ないため、設定が難しいことがわかりました。そうしないと、重複したタスクが完了する可能性があります。これは、プッシュ通知の送信に使用しているため、回避することが非常に重要です。

現在の設定では、デプロイが展開されると 3 ~ 5 分のダウンタイムが発生します。これは、既存のインスタンスがすぐに終了し、新しいインスタンスがセットアップされるまで待たなければならないためです。

これを構成してダウンタイムを減らしながら、最大で 1 つのサービスが稼働していることを確認するより良い方法はありますか?

4

0 に答える 0