Skip to content

chore: upgrade dependency apisix-ingress-controller to 1.3.0 - #998

Merged
AlinsRan merged 1 commit into
apache:masterfrom
AlinsRan:chore-apisix-dep-ingress-1.3.0
Aug 19, 2026
Merged

chore: upgrade dependency apisix-ingress-controller to 1.3.0#998
AlinsRan merged 1 commit into
apache:masterfrom
AlinsRan:chore-apisix-dep-ingress-1.3.0

Conversation

@AlinsRan

@AlinsRan AlinsRan commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Description

Picks up apisix-ingress-controller 1.3.0, which carries 2.2.0.

  • dependency apisix-ingress-controller 1.2.0 -> 1.3.0, chart version 2.16.0 -> 2.16.1
  • Chart.lock and the vendored tarball regenerated with helm dependency update

helm lint passes and helm template renders apache/apisix-ingress-controller:2.2.0 alongside ghcr.io/api7/adc:0.27.1. No values changed, so the generated README is untouched.

Upgrading needs the CRDs applied first

Worth knowing for anyone moving an existing install to this version, because it fails silently otherwise. Helm applies crds/ on install and skips it on upgrade, so a plain helm upgrade leaves the Gateway API CRDs at v1.3.0 while 2.2.0 reads the L4 routes through gateway.networking.k8s.io/v1 only. Verified on a clean kind cluster, upgrading from chart 1.2.2:

$ helm upgrade ic apisix/apisix-ingress-controller     # no CRD step
$ kubectl get crd tcproutes.gateway.networking.k8s.io -o jsonpath='{.spec.versions[*].name}'
v1alpha2
$ kubectl get tcproutes.v1.gateway.networking.k8s.io -A
error: the server doesn't have a resource type "tcproutes"

TCPRoute, UDPRoute and TLSRoute stop being reconciled, and l4routepolicies is never created either, so L4RoutePolicy cannot be used. Applying the CRDs first fixes both:

$ kubectl apply --server-side --force-conflicts -f crds
$ kubectl get crd tcproutes.gateway.networking.k8s.io -o jsonpath='{.spec.versions[*].name}'
v1 v1alpha2

After that the 2.2.0 controller rolls out, a v1 TCPRoute and an L4RoutePolicy both apply cleanly, and the webhooks answer on the v1 paths.

--force-conflicts is the part that is required: helm owns those CRD fields as manager helm, and server-side apply refuses to take fields another manager owns when the values differ. --server-side itself is not strictly required for this bundle — the largest CRD serialises to 242339 bytes against the 262144 byte annotation limit — but the margin is 7%, so it is the safer way to apply them.

The chart's ## Upgrading Chart section says nothing about this today. Happy to send that as a follow-up to the ingress-controller chart.

@AlinsRan
AlinsRan merged commit 8d8948b into apache:master Aug 19, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants