pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTING

Đang mở Phù hợp với người mới
#7,626 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

@Dhirenderchoudhary đang làm issue này rồi.

Từ ngày 14/11/2026.

  • #7635 của @Dhirenderchoudhary — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
Nửa ngày
Mức phù hợp với người mới
74/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, kubernetes
Lĩnh vực
devops

Hướng nghiên cứu

Lỗi nằm ở executeK8sTrafficRoutingStageIstio trong kubernetes/deployment/traffic.go và istioTrafficRouting trong kubernetes_multicluster/deployment/traffic.go, nơi host truyền vào generateVirtualServiceManifest cần lấy từ trafficRouting.istio.host và dùng spec.service.name làm phương án dự phòng. Hãy bảo vệ việc truy cập cấu hình Istio khỏi nil theo cách K8S_PRIMARY_ROLLOUT đã làm. Hoàn thành khi manifest của ví dụ FQDN hiển thị trọng số 70/30 và một cấu hình không có khối istio không còn gây panic.

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

Mô tả

What happened:

In the pipedv1 kubernetes and kubernetes_multicluster plugins, the Istio path of K8S_TRAFFIC_ROUTING doesn't read trafficRouting.istio.host ("The service host" in the config reference). It always passes spec.service.name to generateVirtualServiceManifest as the host (executeK8sTrafficRoutingStageIstio in kubernetes/deployment/traffic.go, istioTrafficRouting in kubernetes_multicluster/deployment/traffic.go).

So when the VirtualService routes to a host that isn't the bare service name, e.g. the FQDN used in examples/v0/kubernetes/mesh-istio-canary (istio.host set, no service), the existing route is treated as another host. It keeps 100% of the traffic and a destination without a host is added, while the stage log says primary=70%, canary=30%.

The same line reads cfg.Spec.TrafficRouting.Istio.EditableRoutes without a nil check, so trafficRouting: {method: istio} without an istio: block panics. K8S_PRIMARY_ROLLOUT already handles a missing istio block.

What you expected to happen:

istio.host is used when it's set, falling back to the service name otherwise, and a missing istio block is treated as empty.

How to reproduce it:

App config with:

trafficRouting:
  method: istio
  istio:
    host: traffic-test.default.svc.cluster.local

and a VirtualService whose route destination host is traffic-test.default.svc.cluster.local, then run K8S_TRAFFIC_ROUTING with canary: 30. Calling generateVirtualServiceManifest with the host the stage passes today ("") vs the configured one gives:

host="" ->
  - destination:
      subset: primary
  - destination:
      host: traffic-test.default.svc.cluster.local
      subset: primary
    weight: 100
host="traffic-test.default.svc.cluster.local" ->
  - destination: {host: traffic-test.default.svc.cluster.local, subset: primary}
    weight: 70
  - destination: {host: traffic-test.default.svc.cluster.local, subset: canary}
    weight: 30

Environment:

  • piped version: pipedv1, master (87c6da5)
  • control-plane version: -
  • Others: kubernetes and kubernetes_multicluster plugins
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.