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

Đang mở
  • Có gì không ổn?
#7,023 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

  • #7024 của @parthtiw710 — đã đóng, không merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
docker, helm, kubernetes
Lĩnh vực
ci-cd, devops, infrastructure

Hướng nghiên cứu

Bắt đầu với target run/pipecd trong Makefile và các giá trị Helm cục bộ liên quan để lần theo việc phát hành image và thiết lập lưu trữ host-path. Sau đó, kiểm tra các template deployment.yaml của Redis, MySQL và MinIO. Công việc được xem là hoàn tất khi thiết lập cục bộ hoạt động trên Kind, K3s, K3d, Minikube và các bản phân phối được nêu tên khác mà không gặp lỗi khi kéo image hoặc lỗi quyền lưu trữ.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Go
Star
1.4k
Fork
391
Merge trung bình
4 ngày 1 giờ
Pull request đã merge (30 ngày)
58

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pipe-cd/pipecd

Tất cả issue của pipe-cd/pipecd

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.