AlinsRan opened a new pull request, #998:
URL: https://github.com/apache/apisix-helm-chart/pull/998

   ## Description
   
   Picks up apisix-ingress-controller 1.3.0, which carries 
[2.2.0](https://github.com/apache/apisix-ingress-controller/releases/tag/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:
   
   ```console
   $ 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:
   
   ```console
   $ kubectl apply --server-side --force-conflicts -f crds/gwapi-crds.yaml
   $ kubectl apply --server-side --force-conflicts -f crds/apisixic-crds.yaml
   $ 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to