bug(local-dev): local development setup fails on all non-Kind Kubernetes clusters (K3s, Minikube, K3d)

Aperta
  • Qualcosa non va?
#7,023 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

  • #7024 di @parthtiw710 — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
docker, helm, kubernetes
Ambito
ci-cd, devops, infrastructure

Direzione di ricerca

Inizia con il target run/pipecd del Makefile e con i valori Helm locali associati per tracciare la pubblicazione delle immagini e la configurazione dello storage tramite host-path. Poi esamina i template deployment.yaml di Redis, MySQL e MinIO. Il lavoro è completato quando la configurazione locale funziona su Kind, K3s, K3d, Minikube e sulle altre distribuzioni indicate, senza errori nel recupero delle immagini o problemi di autorizzazioni dello storage.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

kind/bug
What happened?

The local development environment (run via make run/pipecd and the associated local Helm values) is tightly coupled with Kind. When attempting to start the local development cluster on any non-Kind distribution (such as K3s, Minikube, K3d, or MicroK8s), the setup fails due to registry image pulling and persistent storage permission blockers.

Steps to Reproduce
  1. Configure your Kubernetes context to point to a local K3s or Minikube cluster.
  2. Enable local storage by setting localStorageVolumes.enabled: true in the Helm values.
  3. Run make run/pipecd.
  4. Observe:
    • The cluster fails to pull the newly built PipeCD image (ErrImagePull) because it cannot reach/resolve localhost:5001.
    • If the image is manually sideloaded, the database (mysql), cache (redis), and storage (minio) pods crash in a loop with Permission Denied errors.
Root Cause
  1. Registry Hardcoding: The Makefile currently assumes a Kind registry setup and runs a hardcoded docker push localhost:5001/... to publish images. Other clusters running on isolated runtimes (like containerd in K3s/K3d) cannot resolve this host registry out-of-the-box.
  2. Storage Permissions: HostPath directories (e.g. /tmp/pipecd-data/*) created by Kubernetes on the host system are owned by root. However, the MySQL, Redis, and MinIO containers run as non-root users (UID 999 or 1000) and lack write permissions to these directories.
Expected Behavior

The local development setup should be platform-agnostic, supporting K3s, Minikube, K3d, and other distributions seamlessly alongside Kind.

Proposed Solution
  1. Dynamic Environment Detection in Makefile: Update run/pipecd to inspect the active Kubernetes context.
    • For K3s/K3d, save the image and import it directly using sudo k3s ctr --namespace k8s.io images import.
    • For Minikube, load the image using minikube image load.
    • Fall back to docker push only for Kind/standard setups.
  2. Permission Initialization: Add initContainers to the Redis, MySQL, and MinIO template deployments in deployment.yaml that run as root (runAsUser: 0) to chown the mounted directories to the correct non-root UIDs before the main containers start.
Lingua principale
Go
Stelle
1.4k
Fork
391
Merge medio
4g 1h
PR unite (30g)
58

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pipe-cd/pipecd

Tutte le issue di pipe-cd/pipecd

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.