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

Enhancing Kubernetes Security: Enabling API Server Audit Logging

      In the ever-evolving landscape of container orchestration and management, Kubernetes remains at the forefront, empowering organizations to deploy, manage, and scale their containerized applications efficiently. However, as Kubernetes environments grow in complexity, ensuring robust security measures becomes paramount. One crucial aspect of Kubernetes security is audit logging, particularly concerning the Kubernetes API server, which serves as the primary point of interaction with the cluster. The Importance of Audit Logging Audit logging provides visibility into the activities and interactions within a Kubernetes cluster. By recording requests and responses made to the API server, audit logs offer valuable insights into user actions, system modifications, and potential security breaches. This transparency is essential for compliance with regulatory requirements such as HIPAA, GDPR, and PCI DSS, as well as for detecting and investigating security incidents. Understan...
Post a Comment
Read more

Choosing the Right Operating System for Kubernetes

  In the realm of container orchestration, Kubernetes reigns supreme as the de facto standard. It's the go-to platform for managing containerized applications at scale. However, as you delve into the world of Kubernetes deployment, one crucial decision often overlooked is the choice of operating system (OS). While Kubernetes itself is platform-agnostic, the underlying OS can significantly impact performance, security, and overall manageability. In this guide, we'll explore various operating systems suitable for Kubernetes deployment and help you make an informed decision. 1. Linux Distributions: a. Ubuntu: Pros: Ubuntu is one of the most popular choices for Kubernetes deployment due to its widespread adoption and strong community support. It offers a balance between stability and cutting-edge features. Cons: Some argue that Ubuntu's release cycle may introduce instability, especially for production environments requiring long-term support (LTS) versions. b. CentOS/RHEL: P...
Post a Comment
Read more