As of 24 August 2020, IBM Cloud Kubernetes Service is proud to deliver the Kubernetes Ingress controller as the primarily supported Ingress controller in IBM Cloud Kubernetes Service clusters.
The Kubernetes Ingress controller is an NGINX-based Ingress controller that is developed and supported by the Kubernetes open source community.
What does this mean?
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:
- Overview of the Ingress migration tool
- Overview of the Oauth-proxy add-on for the App ID integration
- Overview of the IBM Cloud Certificate Manager integration
How to get started
During the beta, you can use the Kubernetes Ingress controller by running the following:
- Disable an ALB, which uses the custom IBM Ingress controller:
- List available Ingress controller versions:
- The Kubernetes Ingress controller versions are listed under “Kubernetes Ingress versions.”
- Re-enable the ALB with the Kubernetes Ingress controller version:
If you have questions, engage our team via Slack by registering here and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.