Kubernetes Ingress and Gateway API both express application-aware entry into cluster Services, but they come from different generations of the networking model. The current CKA exam runs on Kubernetes v1.35. Kubernetes still supports the stable Ingress API, but the project has frozen Ingress and explicitly recommends Gateway API for new capabilities.
An Ingress resource describes HTTP/HTTPS routing rules and requires an Ingress controller to implement them. Gateway API separates concerns through role-oriented resources such as GatewayClass, Gateway, and HTTPRoute, allowing infrastructure providers, cluster operators, and application developers to own different parts of the traffic contract.
The reusable mental model is client → external network/load balancer → controller-managed entry point → listener/TLS policy → route match → Kubernetes Service → EndpointSlice → Pod. The API object is intent; a controller and infrastructure must make that intent real.
An API object does not forward traffic by itself
Creating Ingress or Gateway resources changes desired state in the Kubernetes API.
A controller watches those resources and configures proxies, cloud load balancers, or other infrastructure according to its implementation.
Troubleshooting should therefore ask both whether the object is valid and whether the expected controller reconciled it. A perfect YAML object with no matching controller produces no working data path.
Controller selection is itself an architectural dependency. A cluster can run several Ingress or Gateway controllers, each watching different classes. The resource must reference or match the controller intended to implement it. During migration, two controllers accidentally reconciling overlapping objects can produce duplicate external addresses or conflicting configuration. Keep class ownership explicit and use status fields to verify which controller accepted the resource. The API schema creates intent; class/controller selection decides which implementation is authorized to act on that intent.
Ingress is an HTTP/HTTPS routing abstraction
Ingress can route based on hostnames and paths, terminate TLS through implementation capabilities, and send traffic to Services.
It does not expose arbitrary protocols in the generic Ingress API; other Service or implementation-specific mechanisms are used for non-HTTP traffic.
The important dependency is the Ingress controller. Different controllers support different annotations and extensions, which is one reason portable design should minimize implementation-specific assumptions where possible.
Ingress path matching and host rules should be tested with realistic URLs, redirects, TLS, and application base paths. Misunderstood path types or rewrite annotations can send a request to the right Service with the wrong URI. That is an application-layer routing defect, not a Service outage. Because many historical Ingress capabilities were controller-specific annotations, inventory those extensions before migrating to another controller or Gateway API. Portability requires understanding which behavior came from Kubernetes and which came from one controller’s configuration model.
Gateway API separates infrastructure and application roles
GatewayClass identifies a class/controller, Gateway represents traffic-handling infrastructure and listeners, and HTTPRoute or other route resources describe how application traffic maps to backends.
That separation lets a platform team own shared gateway infrastructure while application teams own routes within allowed boundaries.
Role separation reduces configuration collision only when attachment and namespace policy are designed deliberately. Otherwise shared gateways can become another broad object every team edits without clear ownership.
GatewayClass creates a natural platform boundary because cluster or infrastructure teams can define which gateway implementation and policy are available, while application teams attach routes without configuring the underlying load balancer directly. That separation can improve multi-team operations if the platform publishes supported listener, TLS, hostname, and namespace policies. Without such a contract, application teams still need intimate controller knowledge and the role-oriented API becomes a naming change rather than a governance improvement.
Route attachment is a trust decision
Gateway API has explicit relationships between Gateways/listeners and Routes.
A Route being created does not automatically mean every Gateway will accept it; listeners can constrain which namespaces or route kinds may attach.
This is a security and multi-tenancy control. Platform teams should test an unauthorized route and verify it cannot attach, not merely test that the intended application route works.
Route attachment should also consider cross-namespace backend references. Gateway API provides reference-grant mechanisms for controlled cross-namespace relationships rather than assuming every route may point to every Service. Those relationships deserve the same review as an API permission because they cross team or tenant boundaries. A route from namespace A to a Service in namespace B can be legitimate shared infrastructure and should be explicit, narrow, and testable. Negative tests confirm that unapproved namespaces cannot create equivalent attachments.
TLS has certificate and hostname dependencies
TLS termination depends on certificate references, secret access, hostname matching, listener configuration, and controller support.
An application can be healthy behind the Service while users see certificate errors or handshake failure at the gateway layer.
Keep certificate ownership and rotation separate from application Pod lifecycle so teams know whether an outage belongs to the workload or to the entry infrastructure.
Certificate management should include Secret scope and controller access. A TLS Secret can be correctly formatted and inaccessible to the controller because of namespace or implementation constraints. Automated certificate issuance introduces another controller and renewal lifecycle. Monitor expiration, issuance errors, and the serving certificate actually presented externally. Renewing a Secret is not enough if the gateway implementation failed to reload it. Treat certificate state, route state, and application state as separate evidence streams.
Services remain the backend abstraction
Ingress and Gateway routes typically target Kubernetes Services, which in turn select EndpointSlices and Pods.
Route success therefore depends on the same Service networking fundamentals as any internal call.
Debug from the inside out: can the backend Pod serve directly, can the Service reach it, then can the gateway route to the Service? This avoids changing external routing to compensate for an unhealthy backend.
Backend health can include more than Pod readiness when the controller or cloud load balancer runs its own probe. A Pod may be Ready while the external load balancer marks every backend unhealthy because the probe path, port, host header, or network policy differs. Trace the exact health-check request as another client. This prevents teams from weakening readiness or Service configuration to solve an external health probe whose assumptions were never aligned with the application.
Ingress remains valid and is no longer evolving
Kubernetes states that Ingress is generally available and not planned for removal, while no further feature development is planned for the API.
That makes migration a requirement decision, not an emergency. Existing Ingress workloads can remain stable; new requirements such as richer role separation or advanced portable routing may justify Gateway API.
Do not migrate simply because Gateway is newer. Migrate when the ownership, routing, portability, or policy benefits justify changing controllers and operational processes.
Migration from Ingress to Gateway API should preserve observable behavior. Build an inventory of hosts, paths, TLS settings, redirects, timeouts, headers, session behavior, annotations, and controller-specific features. Recreate or deliberately retire each behavior and compare production-like traffic. Running both entry paths temporarily can reduce risk when DNS or traffic splitting supports it. The key is equivalence testing, not object translation. A mechanically converted manifest can be syntactically valid and operationally different.
Controller implementation still determines operational behavior
Gateway API is portable at the resource-model level, while implementations differ in data plane, supported features, status conditions, provisioning behavior, metrics, and cloud integration.
Read status conditions and implementation documentation during troubleshooting.
Concepts such as the Kubernetes service-mesh layer can also coexist with Gateway/Ingress. Keep north-south entry, east-west service policy, and application behavior conceptually distinct even when one product implements several of them.
Controller status conditions are high-value troubleshooting evidence because Gateway API resources can report whether references are resolved, listeners accepted routes, and configuration was programmed. Read those conditions before inspecting low-level proxy config. Ingress status is generally less expressive, which often pushes operators toward controller logs sooner. Regardless of API, keep controller logs/metrics and external dataplane evidence available so the team can tell whether reconciliation failed, infrastructure provisioning failed, or traffic reached the proxy and was routed incorrectly.
A practical scenario should test policy as well as reachability
Create two application namespaces, one shared Gateway, an allowed route, and a route that should be denied by listener/namespace policy.
Verify controller status, external address, TLS, route attachment, Service backends, and the denied attachment case.
That exercise produces a reusable model: Kubernetes networking intent is split across API resources with distinct owners; a controller reconciles them; Services remain the workload backend; and status/evidence at each boundary explains whether the system is behaving as designed.
The strongest mental model keeps ownership aligned with resources. Infrastructure teams own GatewayClass and shared Gateway policy; application teams own routes and Services; security may own certificate or attachment constraints; the controller implements the contract. Ingress historically compressed several of those concerns into one resource plus annotations. Gateway API is valuable when organizations actually use the separation to clarify responsibility, reduce implementation-specific coupling, and test unauthorized relationships—not merely because it has more object kinds.
Gateway design should also be read in the wider context of Kubernetes and cloud-native foundations. Gateway/Ingress resources do not replace DNS, Service discovery, EndpointSlices, CNI, or application readiness; they compose with those layers. When an external request fails, follow the stack rather than treating the newest API object as the whole system. That mental model remains valid even when the controller implementation, cloud provider, or gateway product changes.
Migration planning should also include ownership of DNS cutover and rollback. If both Ingress and Gateway paths are live temporarily, the team needs a controlled way to shift traffic, compare behavior, and return users to the old path if the new controller or policy behaves differently. External traffic migration is safer when DNS TTLs, load-balancer addresses, certificates, and observation windows are part of the release plan rather than afterthoughts.
