Pro ยท Lesson 4 of 12

Services, Ingress, and Gateway API

A Service gives Pods a stable address. Ingress and the Gateway API are two different ways to get HTTP in from outside. Neither routes traffic until a controller is installed.

Sign in to save your place.

Picture it this way

Pods change their phone numbers when they are replaced. A Service is the office number that stays. Ingress is one kind of receptionist. The Gateway API is a newer receptionist contract. If nobody is sitting at the desk, the sign on the door does nothing.

Service types

ClusterIP is the default. Other Pods in the cluster use it. It is not reachable from your laptop unless you port-forward.

NodePort opens a port on every node. LoadBalancer asks a cloud, or a local add-on, for an external address. On kind that address often never appears. ExternalName is a DNS alias, not a proxy to Pods.

Type Who can use it Needs
ClusterIP Inside the cluster Nothing extra
NodePort Anyone who can reach a node IP A free high port
LoadBalancer Outside, if a provider answers A cloud controller or a local tunnel

Ingress is stable, and idle without a controller

The Ingress API is networking.k8s.io/v1. An Ingress object names hosts, paths, and a Service. Kubernetes does not ship one Ingress controller. nginx, a cloud controller, or another project has to watch those objects and program a proxy.

Two Ingress objects with the same host can surprise you. The controller's rules, not the core API, decide the winner. Read that controller's docs.

Gateway API is a second front door

Gateway API is not a field inside Ingress. You install its CRDs. The Standard channel is the stable set. The Experimental channel can break between releases.

Gateway API 1.5, released in February 2026, documents Kubernetes 1.30 or later for that release. A newer Gateway API minor can raise that floor. Check the release you install. A Gateway with no GatewayClass controller is as idle as an Ingress with no controller.

You can keep Ingress. New HTTP entry points on a cluster that already runs a conformant Gateway controller are a reason to look at HTTPRoute. Do not rewrite a working Ingress only because a blog said Ingress is gone.

From a browser to a Pod

  1. Gateway
  2. Service
  3. Pods

Step 1 of 3A Gateway or Ingress only works when its controller is running.

Lab: ClusterIP, then a port-forward

This stays inside the cluster. It does not pretend kind created a cloud load balancer.

kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 80
EOF
kubectl get svc hello
kubectl port-forward svc/hello 8080:80

Concept summary

Knowledge check

You applied an Ingress and nothing answers on port 80. What is a likely cause?

Which statement about Gateway API is accurate?

A LoadBalancer Service on kind stays pending. What did you learn?

Official sources

Checked against the linked documentation in October 2026. A later release can move a flag, a price, or a supported pair. Use the page for the version you installed.