Recently, the Kubernetes community has announced that the Ingress NGINX controller will be retired in March 2026. The IBM Cloud Kubernetes Service currently deploys and manages the Kubernetes NGINX Ingress controller for all clusters. We have been diligently working on a plan to determine the path forward for the managed ingress controller of the IBM Cloud Kubernetes Service.

There have been 2 critical requirements in choosing our future plans with respect to the ingress controller:

1. Reduce the impact to our customers as much as possible.
2. Provide a reliable, highly functional, and performant ingress controller that IBM and our customers can depend on.

Since the Kubernetes NGINX Ingress controller retirement announcement, Chainguard has disclosed that they have forked the source of the Kubernetes NGINX Ingress controller and will maintain the source on a best-effort basis. As stated in the linked article, Chainguard will only be maintaining the latest source base and no new features will be added.

Our current plan is to use Chainguard's fork of the Kubernetes NGINX Ingress controller source code and continue to release new patched versions in the IBM Cloud Kubernetes Service throughout the entirety of 2026. All ingress functionality and configuration during this time will remain unchanged and there will be no impact to IBM Cloud Kubernetes Service Ingress controller users.

Because Chainguard's Kubernetes NGINX Ingress controller fork is a temporary, stopgap solution, we have also been investigating the long term plan for a superseding ingress controller for the IBM Cloud Kubernetes Service.

While searching for a replacement ingress controller we are attempting to achieve the following requirements:

1. Maintain as much functionality in the next IBM Cloud Kubernetes Service Ingress controller as the Kubernetes Ingress NGINX controller provided.
2. Expend minimal to no impacts to our customers during this transition.
3. Use an open source ingress controller that has a strong community following and is high quality with a regular patch and release cadence
4. Ensure the ingress controller has a strategic outlook to emerging and forthcoming architectures such as the Kubernetes Gateway API.

After extensive investigation, we have decided to use Traefik proxy as the strategic ingress and gateway API controller for the IBM Cloud Kubernetes Service.

Traefik fills in all the requirement checkboxes outlined.

• First, Traefik provides an extensive set of configuration options for Kubernetes Ingress as well as a rich set of their own CRDs if you wish to use them.
• Next, Traefik has been implementing functionalty to support existing Kubernetes NGINX Ingress annotations to allow for a smoother transition from Kubernetes NGINX Ingress to Traefik along with a migration tool to migrate to native Traefik resources.
• Lastly, Traefik supports the Kubernetes Gateway API, which is the emerging routing architecture for Kubernetes.

The following is a delivery plan for the IBM Cloud Kubernetes Service Ingress controller.

• Release the Kubernetes NGINX Ingress releases built from the Chainguard fork.
• Make Traefik available as an optional ingress controller choice in the IBM Cloud Kubernetes Service for early adopters.

• Make Traefik generally available in the IBM Cloud Kubernetes Service.
• Announce that users will have 6 months to migrate to the Traefik ingress controller
• Deprecate the Kubernetes NGINX Ingress for the IBM Cloud Kubernetes Service

• Continue to update both Traefik and the Kubernetes NGINX Ingress in the IBM Cloud Kubernetes Service.
• Update the documentation with migration steps and release notes.
• Notify users about upcoming Kubernetes NGINX Ingress end of life.

• End of life for the Kubernetes NGINX Ingress controller in the IBM Cloud Kubernetes Service.

Thank you for your attention to this matter! As we progress throughout the year, we will provide documentation updates and additional announcements when upcoming changes are being made.