Kubernetes Networking: Services, Ingress, and NetworkPolicy

Work in a dedicated namespace so policies are easy to reason about and cleanup is one command. Deploy web (NGINX), api (a simple HTTP responder), and db (PostgreSQL), each labelled so Services and NetworkPolicies can select them.

Create the namespace and workloads

kubectl create namespace netlab
kubectl -n netlab create deployment web --image=nginx:1.25 --port=80
kubectl -n netlab create deployment api --image=hashicorp/http-echo:0.2.3 -- -text="api-ok"
kubectl -n netlab create deployment db --image=postgres:16 --port=5432
kubectl -n netlab set env deployment/db POSTGRES_PASSWORD=labpass

Verify all pods are running

kubectl -n netlab get pods -o wide --show-labels

Expected output

NAME                   READY   STATUS    RESTARTS   AGE   IP            LABELS
api-5f8c9d7b6d-k2j9x   1/1     Running   0          40s   10.244.0.12   app=api,...
db-6c8b5f7c9-4mztq     1/1     Running   0          40s   10.244.0.13   app=db,...
web-7d9c4b8f5-rp2lw    1/1     Running   0          40s   10.244.0.11   app=web,...

What this teaches: The three-tier app gives every network primitive something to connect; deploy the workloads before the wiring.

Pod IPs are ephemeral, they change on every restart, reschedule, or scale event. A Service gives a stable virtual IP and DNS name that load-balances across matching pods. The default type, ClusterIP, is reachable only from inside the cluster, which is the correct default for anything that is not public-facing.

Do the same for api and db, then inspect what was created:

Expose remaining tiers and inspect the Services

kubectl -n netlab expose deployment api --port 8080 --target-port 5678
kubectl -n netlab expose deployment db --port 5432 --target-port 5432
kubectl -n netlab get svc

Expected output

NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
api    ClusterIP   10.96.214.87    <none>        8080/TCP   10s
db     ClusterIP   10.96.108.201   <none>        5432/TCP   8s
web    ClusterIP   10.96.45.173    <none>        80/TCP     2m

Prove internal reachability by curling the Service name (not the pod IP) from a throwaway pod. CoreDNS resolves web because the test pod lives in the same namespace:

Test Service DNS from inside the cluster

kubectl -n netlab run test --rm -it --image=busybox:1.36 -- wget -qO- http://web

Expected output (NGINX welcome page, truncated)

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

What this teaches: ClusterIP is the internal default; it proves pods can find each other without any external exposure.

Before going further, be deliberate about the exposure model, because it decides your attack surface:

• ClusterIP, internal only. Use for api and db; they should never be reachable from outside.
• NodePort, opens a high port (30000-32767) on every node. Fine for quick demos, poor for production: no TLS, no host routing, and it bypasses your edge controls.
• Ingress, one external entry point that routes many hostnames and paths to many Services, terminates TLS, and centralizes logging and rate limiting. This is what you will use for web.

You can see the NodePort mechanics without keeping it: patch the Service, observe the allocated port, then revert so the lab continues with only Ingress as the external path.

Peek at NodePort behaviour, then revert

kubectl -n netlab patch svc web -p '{"spec":{"type":"NodePort"}}'
kubectl -n netlab get svc web   # note the 80:31xxx/TCP mapping
kubectl -n netlab patch svc web -p '{"spec":{"type":"ClusterIP"}}'

What this teaches: Comparing the three types side by side makes the exposure ladder concrete: internal, node port, then L7 routing.

An Ingress resource is just a rule set; the controller you installed in setup turns it into live reverse-proxy config. This rule sends any request whose Host header is web.lab.tyfsadik.org to the web Service on port 80.

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: web }
spec:
  ingressClassName: nginx
  rules:
    - host: web.lab.tyfsadik.org
      http:
        paths:
          - path: /
            pathType: Prefix
            backend: { service: { name: web, port: { number: 80 } } }

Apply and confirm the rule is programmed

kubectl -n netlab apply -f ingress.yaml
kubectl -n netlab get ingress web
kubectl -n ingress-nginx get svc ingress-nginx-controller   # grab the EXTERNAL-IP

Expected output

NAME   CLASS   HOSTS                  ADDRESS        PORTS   AGE
web    nginx   web.lab.tyfsadik.org   203.0.113.50   80      15s

Since the lab hostname is not in public DNS, send the Host header explicitly against the controller's external address (203.0.113.50 below is a documentation address, substitute your controller's actual EXTERNAL-IP):

Curl through the Ingress

curl -s -H 'Host: web.lab.tyfsadik.org' http://203.0.113.50/ | head -5

What this teaches: Ingress routes by host and path; one entry point can serve many backends, which is the production pattern.

Everything above worked because CoreDNS answers names like web, web.netlab, and the fully qualified web.netlab.svc.cluster.local. Take thirty seconds to see the record directly, you will need this reflex later when debugging egress policies, because a default-deny egress rule also blocks DNS if you forget to allow it.

Resolve the Service from inside a pod

kubectl -n netlab run dnscheck --rm -it --image=busybox:1.36 -- nslookup web.netlab.svc.cluster.local

Expected output

Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      web.netlab.svc.cluster.local
Address 1: 10.96.45.173 web.netlab.svc.cluster.local

What this teaches: CoreDNS is the service discovery backbone; if names resolve, the platform's wiring is healthy.

Default-deny then explicit-allow is the zero-trust posture for pod traffic.

A NetworkPolicy with an empty podSelector selects every pod in the namespace, and an empty rule set means "allow nothing". The moment this applies, all ingress and egress in netlab is dropped, including DNS lookups from your pods, which is why step 07 adds DNS egress back immediately.

# default-deny.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: netlab
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Confirm the policy exists and selects all pods

kubectl -n netlab get networkpolicy
kubectl -n netlab describe networkpolicy default-deny | head -12

Expected output

NAME            POD-SELECTOR   AGE
default-deny    <none>         6s

What this teaches: Default-deny flips the cluster from allow-all to deny-all; it is the moment network policy becomes real.

Now open exactly the paths the app needs: api pods may reach db on TCP 5432 (both the ingress half on db and the egress half on api, because default-deny blocks both directions), every pod may reach CoreDNS on UDP/TCP 53 so name resolution keeps working, and the ingress-nginx controller may reach web on port 80 so the external path from step 04 survives default-deny. Nothing else in the namespace can initiate anything.

# allow-api-to-db.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: netlab
spec:
  podSelector:
    matchLabels: { app: db }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: api }
      ports:
        - protocol: TCP
          port: 5432
---
# allow-dns.yaml - egress to kube-dns so lookups survive default-deny
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: netlab
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

# allow-api-egress-to-db.yaml, the egress half default-deny also blocks

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-egress-to-db
  namespace: netlab
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: [Egress]
  egress:
    - to:
        - podSelector:
            matchLabels: { app: db }
      ports:
        - protocol: TCP
          port: 5432

# allow-ingress-to-web.yaml, lets the ingress controller reach web under default-deny

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-web
  namespace: netlab
spec:
  podSelector:
    matchLabels: { app: web }
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - protocol: TCP
          port: 80

Apply the allow rules

kubectl apply -f allow-api-to-db.yaml
kubectl apply -f allow-api-egress-to-db.yaml
kubectl apply -f allow-dns.yaml
kubectl apply -f allow-ingress-to-web.yaml
kubectl -n netlab get networkpolicy

What this teaches: Each allow rule is a deliberate hole; writing them forces you to state what the app actually needs.

Segmentation that you have not tested is a hope, not a control. From a pod labelled app=other (which no policy permits), the database connection must fail; from an api pod it must succeed.

Launch an unauthorized pod and test the DB path

kubectl -n netlab run other --rm -it --image=busybox:1.36 --labels app=other -- nc -zv -w3 db 5432 || echo denied
kubectl -n netlab run api-probe --rm -i --image=busybox:1.36 --labels app=api -- nc -zv -w3 db 5432

Expected output

denied                                  # from the 'other' pod (labeled app=other, which no policy selects)
db (10.96.108.201:5432) open            # from an 'api' pod

The external path should still work end to end, because Ingress traffic enters through the controller in its own namespace and the web pod is only serving, not initiating:

Re-test the public path

curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: web.lab.tyfsadik.org' http://203.0.113.50/

Expected output

200

What this teaches: Proving both the allow and the deny is the complete test; half-tested policy is assumed policy.