September 2, 2020 By Cale Rath 3 min read

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.

What’s next?

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:

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:
    ibmcloud ks alb configure <environment-type> --alb-id <alb-id> --disable
  • List available Ingress controller versions:
    ibmcloud ks alb versions
  • The Kubernetes Ingress controller versions are listed under “Kubernetes Ingress versions.”
  • Re-enable the ALB with the Kubernetes Ingress controller version:
    ibmcloud ks alb configure <environment-type> --alb-id <alb-id> --enable --version <version>

Have questions?

See the feature-rich set of documents describing the IBM Kubernetes Ingress controller.

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.

More from Announcements

Success and recognition of IBM offerings in G2 Summer Reports  

2 min read - IBM offerings were featured in over 1,365 unique G2 reports, earning over 230 Leader badges across various categories.   This recognition is important to showcase our leading products and also to provide the unbiased validation our buyers seek. According to the 2024 G2 Software Buyer Behavior Report, “When researching software, buyers are most likely to trust information from people with similar roles and challenges, and they value transparency above other factors.”  With over 90 million visitors each year and hosting more than 2.6…

Manage the routing of your observability log and event data 

4 min read - Comprehensive environments include many sources of observable data to be aggregated and then analyzed for infrastructure and app performance management. Connecting and aggregating the data sources to observability tools need to be flexible. Some use cases might require all data to be aggregated into one common location while others have narrowed scope. Optimizing where observability data is processed enables businesses to maximize insights while managing to cost, compliance and data residency objectives.  As announced on 29 March 2024, IBM Cloud® released its next-gen observability…

Unify and share data across Netezza and watsonx.data for new generative AI applications

3 min read - In today's data and AI-driven world, organizations are generating vast amounts of data from various sources. The ability to extract value from AI initiatives relies heavily on the availability and quality of an enterprise's underlying data. In order to unlock the full potential of data for AI, organizations must be able to effectively navigate their complex IT landscapes across the hybrid cloud.   At this year’s IBM Think conference in Boston, we announced the new capabilities of IBM watsonx.data, an open…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters