Échec du conteneur Gorse runAsNonRoot

Problème

Les conteneurs du moteur de recommandation Gorse (master, server, worker) plantent immédiatement au démarrage lors de l'exécution avec runAsNonRoot: true de Kubernetes et un UID personnalisé comme 65532.

Contexte / Conditions de déclenchement

Les pods Gorse affichent le statut CrashLoopBackOff ou Error

Les logs du pod affichent :

{"level":"fatal","ts":...,"caller":"model/built_in.go:95","msg":"failed to get user directory","error":"user: unknown userid 65532"}

Le Deployment a securityContext.runAsNonRoot: true et runAsUser: 65532
Utilisation des images gorse officielles (zhenghaoz/gorse-master, zhenghaoz/gorse-server, zhenghaoz/gorse-worker)

Cause racine

La base de code gorse appelle os.UserHomeDir() de Go pendant l'initialisation dans model/built_in.go. Cette fonction requiert que l'UID en cours d'exécution ait une entrée dans /etc/passwd. Lors de l'exécution en tant qu'utilisateur non-root n'existant pas dans le fichier passwd du conteneur, la recherche échoue.

Solution

Supprimez les contraintes runAsNonRoot et runAsUser du contexte de sécurité du pod :

# Avant (cassé)
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65532
        fsGroup: 65532

# Après (fonctionnel)
spec:
  template:
    spec:
      securityContext:
        fsGroup: 1000

Appliquez à tous les Deployments gorse :

deployment-master.yaml
deployment-server.yaml
deployment-worker.yaml
init-db-job.yaml (si vous utilisez un init job)

Vérification

Après mise à jour du contexte de sécurité :

Supprimez les pods existants en crash : kubectl delete pods -l app.kubernetes.io/name=gorse -n gorse
Attendez que les nouveaux pods démarrent
Vérifiez les logs : kubectl logs -l app=gorse-master -n gorse
Vérifiez que master affiche la connexion au data store et au cache store

Notes

Il s'agit d'une limitation des images gorse officielles, pas d'un problème Kubernetes
Le projet gorse pourrait corriger cela dans les versions futures en ne nécessitant pas le répertoire home
Si la politique de sécurité nécessite une exécution non-root, vous devriez créer des images gorse personnalisées avec les entrées /etc/passwd appropriées pour l'UID souhaité
Les images Redis Stack utilisées pour le cache gorse ont le même problème avec l'UID 65532

Problèmes connexes

Gorse GitHub : Les images ne documentent pas cette exigence
Des problèmes similaires affectent d'autres applications Go utilisant os.UserHomeDir()

gorse-runasnonroot-failure