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 Open source

Cultivating Careers, Communities and Companies with Open Source

6 min read - The soft skills you need to succeed in open source. I've had the privilege of working in open source for the last 20+ years. I started off as a volunteer, as most do in open source, attempting to learn something new. Even though I didn't fully understand what open source was at the time, I really involved myself in the community and got so much in return. While running small projects, I learned an incredible amount about the skills needed…

How to Use an Ansible Playbook to Manage Secrets for Infrastructure Provisioned on IBM Cloud

6 min read - Instructions and code that show you how to use Ansible playbooks to manage the lifecycle of a secret in IBM Secret Manager. IBM Cloud Secrets Manager is built on open-source HashiCorp Vault, and it allows you to dynamically create and manage secrets. For infrastructure or services provisioned from IBM Cloud, you need to rotate the secrets on a timely basis. What is an Ansible playbook? Many IT teams have a common requirement to manage the configuration for systems in an…

Kubernetes Audit Logs: Answering the Who, When and What

3 min read - Learn how to set up log forwarding and collect audit logs that are passed through the Kubernetes API server to IBM Log Analysis to check who initiated a request and when they did so. As a cluster administrator, by following the simple steps in this blog post, you should be able to answer questions about Kubernetes audit logs, like who initiated a request to delete a Kubernetes resource? When did it happen? On what did it happen? What are audit…

IBM Newsletters

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