IBM Cloud Kubernetes Service is replacing the custom IBM NGINX-based Ingress controller that is currently deployed in clusters with the Kubernetes Ingress controller. The Kubernetes Ingress controller is first released as a beta feature, meaning that you can change your cluster’s default Ingress controller (ALB), via command line, from the custom IBM NGINX Ingress controller to the Kubernetes Ingress controller. When the Kubernetes Ingress controller becomes generally available in IBM Cloud Kubernetes Service clusters, it will be provisioned as the default Ingress controller (ALB) in all new clusters that run Kubernetes version 1.18 and later.
We are providing a migration tool that can be used to migrate Ingress resources from the IBM NGINX format to the Kubernetes format. This migration tool provides the capability to accurately migrate nearly all Ingress resources and ConfigMap data and provide a mechanism to test and enhance the migrated results before making the complete migration to the Kubernetes Ingress controller.
Additionally, we introducing an integration with IBM Cloud Certificate Manager. One Certificate Manager instance is created for each cluster, which contains the Ingress certificate for your default Ingress subdomain. You can also upload your own certificates to your cluster’s Certificate Manager instance and use the Ingress secret CLI commands to import their secrets into your cluster.
Features that are unique to the IBM Ingress controller, such as the integration with IBM Cloud App ID, continue to exist. App ID use in the Kubernetes Ingress controller is managed using the Oauth2-Proxy open source project. The IBM Cloud Kubernetes Service team released an add-on which is used to provide straightforward provisioning and configuration of Oauth2-Proxy for your Kubernetes Ingress controller.
Six months after the Kubernetes Ingress controller is made generally available, IBM Cloud Kubernetes Service is sunsetting the custom IBM NGINX Ingress controller. After this sunset date, any IBM NGINX Ingress controllers will not be automatically migrated and will continue to operate. However, support from the IBM Cloud Kubernetes Service team is discontinued.
Why are we doing this?
Moving to the Kubernetes Ingress controller as the primary Ingress controller for clusters has several advantages. First, we’re continuing to enhance the design and architecture of the Kubernetes project. Many helpful features that are available in the Kubernetes Ingress controller are not available in the custom IBM NGINX Ingress controller.
Next, since the Kubernetes Ingress controller is available via open source, there are many other companies and individuals using and contributing code. In fact, the IBM Cloud Kubernetes Service team directly contributes to this project. If you are using the Kubernetes Ingress controller in another cloud provider or an on-premises environment, your Ingress resources can be directly copied to your IBM Cloud Kubernetes Service cluster and will work with your cluster’s Ingress controller (ALB).
Finally, IBM Cloud Kubernetes Service can more quickly provide Ingress builds with security updates and code enhancements that match new features provided in Kubernetes releases.
This is the first in a series of blog posts for the IBM Cloud Kubernetes Service release of the Kubernetes Ingress controller. These blog posts will explore enhancements to provide functional equivalency, simplicity, and a better user experience for the Kubernetes Ingress controller, including the following: