Skip to main content

Deprecating Networking Ingress API version in Kubernetes 1.22

 

Intro

Kubernetes deprecates API versions over time. Usually this affects alpha and beta versions and only requires changing the apiVersion: line in your resource file to make it work.

However with this Ingress object version change, additional changes are necessary.

Basics

For this post I am quickly creating a new cluster via Kind (Kubernetes in Docker). Once done, we can see which API versions are supported by this cluster (version v1.21.1).

$ kubectl api-versions | grep networking
networking.k8s.io/v1
networking.k8s.io/v1beta1

Kubernetes automatically converts existing resources internally into different supported API versions. So if we create a new Ingress object with version v1beta1 on a recent cluster version, you will receive a deprecation warning - and the same Ingress object will exist both in version v1beta1 and v1.

Create

$ cat ingress_beta.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: clusterpirate-ingress
spec:
  rules:
  - http:
      paths:
      - path: /clusterpirate
        backend:
          serviceName: clusterpirate
          servicePort: 8090

$ kubectl apply -n default -f ingress_beta.yaml 
Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
ingress.networking.k8s.io/clusterpirate-ingress created

Check

To verify this, you can view or export the same resource in the required API version and get a different document back. This also helps with the actual migration, as it includes the required layout or configuration.

$ kubectl get ingress.v1beta1.networking.k8s.io -n default clusterpirate-ingress -o yaml
Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: clusterpirate
          servicePort: 8090
        path: /clusterpirate

$ kubectl get ingress.v1.networking.k8s.io -n default clusterpirate-ingress -o yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: clusterpirate
            port:
              number: 8090
        path: /clusterpirate
        pathType: ImplementationSpecific

Migrate

To change your Ingress objects (within helm charts for example), we need to change the apiVersion: as well as adding the pathType: field, which can be either Prefix or ImplementationSpecific.

$ diff ingress_beta.yaml ingress_v1.yaml 
1c1
< apiVersion: networking.k8s.io/v1beta1
---
> apiVersion: networking.k8s.io/v1
9a10
>         pathType: Prefix
11,12c12,15
<           serviceName: clusterpirate
<           servicePort: 8090
---
>           service:
>             name: clusterpirate
>             port:
>               number: 8090

Conclusions

  • API versions change over time. 
  • Kubernetes tracks resources internally in different versions.
  • Usually the version upgrade process is somewhat easier.

Links

Labels:

Comments

Post a Comment

Popular posts from this blog

Manual Kubernetes TLS certificate renewal procedure

Intro Kubernetes utilizes TLS certificates to secure different levels of internal and external cluster communication.  This includes internal services like the apiserver, kubelet, scheduler and controller-manager etc. These TLS certificates are created during the initial cluster installation and are usually valid for 12 months. The cluster internal certificate authority (CA) certificate is valid for ten years. There are options available to automate certificate renewals, but they are not always utilised and these certs can become out of date. Updating certain certificates may require restarts of K8s components, which may not be fully automated either. If any of these certificates is outdated or expired, it will stop parts or all of your cluster from functioning correctly. Obviously this scenario should be avoided - especially in production environments. This blog entry focuses on manual renewals / re-creation of Kubernetes certificates. For example, the api-server certificate below...
Post a Comment
Read more

Analysing and replaying MySQL database queries using tcpdump

Why There are situations where you want to quickly enable query logging on a MySQL Database or trouble shoot queries hitting the Database server in real-time. Yes, you can enable the DB query log and there are other options available, however the script below has helped me in many cases as it is non intrusive and does not require changing the DB server, state or configuration in any way. Limitations The following only works if the DB traffic is not encrypted (no SSL/TLS transport enabled). Also this needs to be run directly on the DB server host (as root / admin). Please also be aware that this should be done on servers and data you own only. Script This script has been amended to suit my individual requirements. #!/bin/sh tcpdump -i any -s 0 -l -w - dst port 3306 | strings | perl -e ' while(<>) { chomp; next if /^[^ ]+[ ]*$/;   if(/^(ALTER|COMMIT|CREATE|DELETE|DROP|INSERT|SELECT|SET|UPDATE|ROLLBACK)/i) {     if (defined $q) { print "$q\n"; }     $q=$_; ...
Post a Comment
Read more