• selector — which Pods, by label, in this namespace
• port — what callers dial on the Service
• targetPort — the container port; a named port survives renumbering
• type defaults to ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: pinboard-api
  namespace: pinboard
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: pinboard-api
  ports:
    - name: http
      port: 8080
      targetPort: http

• port — on the Service's virtual IP
• targetPort — on the Pod; number or port name
• nodePort — on every node's real IP (NodePort/LoadBalancer only)

spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: pinboard-web
  ports:
    - name: http
      port: 8080        # ClusterIP:8080
      targetPort: http  # container port 8080
      nodePort: 30080   # node:30080

Callers inside: pinboard-web:8080. From your laptop with kind: localhost:30080 if mapped.

Headless (clusterIP: None): no virtual IP, no kube-proxy rules. DNS returns one A record per ready Pod — the client decides.

• Stable per-Pod names for StatefulSets (session 08)
• Clients that do their own pooling: databases, gRPC, Kafka

ExternalName: a DNS alias to something outside the cluster — swap a managed database for an in-cluster one without touching the app.

apiVersion: v1
kind: Service
metadata:
  name: pinboard-db
  namespace: pinboard
spec:
  clusterIP: None          # headless
  selector:
    app.kubernetes.io/name: pinboard-db
  ports:
    - name: postgres
      port: 5432
      targetPort: postgres

• CoreDNS runs in kube-system; kubelet points every Pod at it
• Same namespace → the short name is enough
• Cross-namespace → add the namespace
• Headless → A records for the Pods; SRV records for named ports

pinboard-api
pinboard-api.pinboard
pinboard-api.pinboard.svc
pinboard-api.pinboard.svc.cluster.local

# a headless Pod, by ordinal
pinboard-db-0.pinboard-db.pinboard.svc.cluster.local

# <service>.<namespace>.svc.<cluster-domain>

• networking.k8s.io/v1 — the only version since 1.22
• ingressClassName: nginx, never the old annotation
• pathType: Prefix, Exact or ImplementationSpecific
• The second rule sends / (Prefix) to pinboard-web port http
• Longest path wins, so /api beats /

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: pinboard
  namespace: pinboard
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service: { name: pinboard-api, port: { name: http } }

• The certificate lives in a kubernetes.io/tls Secret (tls.crt + tls.key)
• The controller terminates TLS; traffic to Pods is plain HTTP inside the cluster
• cert-manager issues and renews Let's Encrypt certificates automatically
• For mTLS between Pods you want a service mesh, not an Ingress

spec:
  ingressClassName: nginx
  tls:
    - hosts: ["pinboard.example.com"]
      secretName: pinboard-tls
  rules:
    - host: pinboard.example.com
      http:
        paths: [ ... ]

In the lab we stay on plain HTTP over localhost.

• parentRefs attaches the route to a Gateway
• matches replaces pathType
• backendRefs points straight at Services — add weight for canaries
• A second route for / → pinboard-web completes it

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: pinboard
  namespace: pinboard
spec:
  parentRefs:
    - name: pinboard-gw
  rules:
    - matches:
        - path: { type: PathPrefix, value: /api }
      backendRefs:
        - name: pinboard-api
          port: 8080

• podSelector — the Pods this policy protects
• policyTypes — which directions it governs
• from — podSelector, namespaceSelector or ipBlock
• The companion policy lets only web and ingress-nginx reach the API on 8080

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: db-only-from-api, namespace: pinboard }
spec:
  podSelector:
    matchLabels: { app.kubernetes.io/name: pinboard-db }
  policyTypes: ["Ingress"]
  ingress:
  - from:
    - podSelector:
        matchLabels: { app.kubernetes.io/name: pinboard-api }
    ports:
    - port: 5432