Nous déployons une application Laravel sur Kubernetes. L'application elle-même n'est pas un problème, mais les travailleurs de la file d'attente le sont. Nous avons lu de multiples sources que l'exécution des travailleurs de file d'attente comme un déploiement séparé est recommandé. Donc, ci-dessous la partie kubeconfig qui exécute le travailleur de queue comme une commande. php artisan queue:work
Je comprends qu'il fonctionne comme PID1. Ainsi, lorsque le processus s'arrête, Kubernetes redémarre automatiquement la nacelle. Cependant, lorsque nous supprimons le pod, il faut un certain temps (environ 20 secondes) avant qu'il ne s'arrête, et il se termine avec le code de sortie suivant 137 au lieu de 0 . Je peux voir ça quand je suis exec dans le pod. Il retourne terminated with exit code 137 à la suppression.
Sur cet article J'ai lu que Laravel (nous utilisons 7.x) est asynchrone, et devrait réagir aux signaux SIGTERM. Donc, ne devrait-il pas être logique que lorsque nous arrêtons le pod, Kubernetes envoie un signal SIGTERM, et devrait gracieusement arrêter le pod ? Et gracieusement devrait être un exitcode 0 n'est-ce pas ?
J'espère que quelqu'un pourra m'expliquer ce que je fais de mal ici.
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: hip-prod
name: worker
labels:
worker: worker
spec:
minReadySeconds: 5
replicas: 1
revisionHistoryLimit: 1
selector:
matchLabels:
worker: worker
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 50%
type: RollingUpdate
template:
metadata:
labels:
worker: worker
spec:
nodeSelector:
"beta.kubernetes.io/os": linux
containers:
- name: worker
image: my-laravel-image/app:latest
command: ["php", "artisan", "queue:work"]
imagePullPolicy: Always
