Overview
A typical engagement starts with a platform team that runs several Kubernetes clusters and learns that the Ingress NGINX controller is retired and its repository archived. The clusters work, but nobody has a list of which Ingress resources exist, which annotations they depend on, or what would replace them.
Challenge
The Kubernetes project says none of the alternatives is a direct drop-in replacement. Annotations are not an extension point in Gateway API, snippets have no equivalent, and a controller that gets no security fixes stays in the request path until the last hostname moves. Without an inventory, the effort and the order of work are guesses.
Environment
Several Kubernetes clusters, some on a managed cloud service and some self-managed, running the community Ingress NGINX controller. Ingress resources are owned by many application teams, and some carry snippet annotations and ConfigMap overrides.
Approach
AceMQ engineers run the Kubernetes check for the controller in every cluster, then export each Ingress resource with its annotations, snippets and ConfigMap settings. Each one is mapped to Gateway API resources, to F5's NGINX Ingress Controller or to another controller, and the gaps are listed. The converted routes are tested beside the old controller on a separate external address before any hostname moves.
Solution
- Cluster-by-cluster check for Ingress NGINX pods, including clusters without a clear owner
- Inventory of Ingress resources, annotations, snippets, ConfigMap overrides, TLS secrets and hostname owners
- Route-by-route mapping to Gateway API resources, with ingress2gateway used as a starting point and its warnings reviewed
- List of behavior with no standard equivalent, such as authentication, timeouts and custom directives, and the extension or policy each needs
- Written comparison of a Gateway API implementation, F5's NGINX Ingress Controller and another Ingress controller against the inventory
- Parallel-run and cutover plan, hostname by hostname, with a rollback point at each step
Outcome
The engagement delivers the written inventory, a route-by-route mapping with its gaps, a recommended destination with the reasoning, and a parallel-run and cutover plan the customer's own engineers can execute. AceMQ can carry out the cutover alongside them if the customer wants it.
Technologies
NGINX
KubernetesGateway APIIngress NGINX
PostgreSQL
Docker
Amazon EKS
Prometheus
Redis
dbt
Kafka
