Migrating your ingresses to K3s 1.20+ API format
Kubernetes version 1.20+ introduces the
networking.k8s.io API version as stable. If you have ingresses that predate K3S 1.20, you have until Kubernetes 1.22 to update them. Until then, if you use old-style ingress definitions, you will receive a warning like
Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress when you apply the ingress to a cluster.
What do I need to do?
If you have an ingress definition that looks like the following:
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: fabric-suzuhara-ingress namespace: minecraft annotations: kubernetes.io/ingress.class: traefik spec: rules: - host: m0test.suzuhara.moenet.internal http: paths: - path: / backend: serviceName: fabric-suzuhara-service servicePort: 25565
Then you need to convert some things to work with the newer, stable
Ingress resource and
networking.k8s.io/v1 API version. An example would be the following:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: mysterium-dvpn-node-ingress annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: dvpn.ryza.suzuhara.internal http: paths: - path: / pathType: Prefix backend: service: name: mysterium-dvpn-node-svc port: number: 4449
The main difference is that port now defines explicit
service fields here, which is drastically different than the earlier, non-stable
extensions/v1beta1 version. Some of the other main changes in /V1 include:
service.port.name(for string values)
service.port.number(for numeric values)
pathTypeno longer has a default value in v1;
ImplementationSpecificmust be specified for each.
Make sure you consult the Kubernetes Documentation for the updated specification for Ingresses and Networking resources.
- Before apply new modification, you can run:
kubectl apply -f some-yaml-file.yaml --dry-run=serverto validate file format and data.
- GKE will block cluster upgrate to API 1.22 if we still using deprecated APIs.