pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTING

Aperta Adatta ai principianti
#7,626 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@Dhirenderchoudhary ci sta già lavorando.

Dal 14/11/2026.

  • #7635 di @Dhirenderchoudhary — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
Mezza giornata
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
devops

Direzione di ricerca

Il bug si trova in executeK8sTrafficRoutingStageIstio in kubernetes/deployment/traffic.go e in istioTrafficRouting in kubernetes_multicluster/deployment/traffic.go, dove l'host passato a generateVirtualServiceManifest dovrebbe provenire da trafficRouting.istio.host e ripiegare su spec.service.name. Proteggi l'accesso alla configurazione Istio da nil come già fa K8S_PRIMARY_ROLLOUT. È completato quando il manifest per l'esempio FQDN mostra pesi 70/30 e una configurazione senza blocco istio non causa più un panic.

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

Descrizione

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
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.