2. ClusterIP: The Internal Phone Extension

From Scratch (The Analogy)

Imagine a team of accounting workers inside the building. They move desks constantly (in Kubernetes, Pods are destroyed and recreated with new internal IPs all the time). If the sales team needs to call accounting, they can't memorize individual desk numbers. Instead, management sets up a permanent internal phone extension: Dial 400 for Accounting. No matter which desk the accounting workers move to, dialing 400 always routes you to an available accountant.

6-Year DevOps Level

ClusterIP is the default Kubernetes service type. It exposes the service on an internal cluster-only IP.

• The Mechanics: It creates a stable virtual IP (VIP) and DNS entry (e.g., my-svc.my-namespace.svc.cluster.local) inside the cluster.
• How it actually routes traffic: It relies on kube-proxy. A senior engineer knows that kube-proxy usually runs in IPVS or iptables mode, modifying the Linux kernel netfilter rules on each node to intercept traffic hitting the ClusterIP and randomly (or via round-robin) forward it to a real Pod backing IP.
• Senior Gotcha: ClusterIPs are non-routable outside the cluster. If an application cannot talk to a database via ClusterIP, a senior engineer checks CoreDNS logs, reviews Endpoints or EndpointSlices (kubectl get endpointslices) to ensure backend pods are actually marked "Ready" by their readiness probes.

3. NodePort: The Dedicated Backdoor

From Scratch (The Analogy)

Now, say an external vendor needs direct access to a specific internal system. The building manager decides to open a very specific side door on the outside of the building—say, Door Room 32000. Anyone from the outside world can walk up to any side wall of the building, find Door 32000, and they will be instantly tunneled straight to that internal team's desk.

6-Year DevOps Level

NodePort builds on top of ClusterIP. It opens a specific port (by default, between 30000-32767) on every single virtual machine (Worker Node) in your cluster.

• The Mechanics: If you target http://<Any-Node-IP>:32000, the node's network stack receives the traffic and routes it to the underlying ClusterIP service.
• Senior Perspective: In enterprise production, you almost never expose NodePorts directly to the public internet because it's a security risk and requires clients to track ephemeral EC2 instance IPs.
• The "Why": Why do we need it? Because external Enterprise Load Balancers (like AWS ALBs or NLBs) use NodePorts as target groups to bridge public traffic into the private cluster network.

4. Ingress vs. ALB (AWS Load Balancer Controller)

From Scratch (The Analogy)

Having 50 different side doors (NodePorts) for 50 different services is chaotic. Instead, you build a Grand Front Lobby (The Ingress) with a single front door. A receptionist sits there. When a visitor walks in and says, "I want to go to /shipping," the receptionist looks at a rulebook and directs them to the elevator. If a visitor says, "I want to go to /billing," they are directed to a different floor.

6-Year DevOps Level

An Ingress is just a Kubernetes specification (a set of routing rules based on HTTP paths or hostnames). It does nothing by itself without an Ingress Controller to execute it.

In AWS EKS, the golden standard is the AWS Load Balancer Controller, which automatically provisions an AWS ALB (Application Load Balancer) in your AWS account when you apply an Ingress manifest.

# A Senior Engineer's Ingress Spec
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip # KEY SENIOR CONFIG
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

• Deep Dive - Target-type instance vs ip: * instance mode routes traffic from the ALB -> NodePort on the EC2 worker node -> kube-proxy -> Pod. This adds an extra network hop.
• ip mode (leveraging AWS VPC CNI) routes traffic directly from the ALB into the Pod's private IP. This completely bypasses NodePort and kube-proxy, slashing latency and maximizing performance. A 6-year veteran designs for target-type: ip.

5. Egress: Leaving the Building Safely

From Scratch (The Analogy)

Workers inside the building occasionally need to look up info on the public internet or send mail out. However, you don't want just any worker downloading random files or leaking data. The building has a strictly managed Outbound Mailroom (Egress Gateway) that checks where packets are going before letting them leave the building.

6-Year DevOps Level

Egress refers to traffic originating inside the cluster going out (to the internet, or to a legacy database outside the cluster).

• The Setup: In a secure EKS setup, worker nodes live in Private Subnets. Their outbound path goes through an AWS NAT Gateway assigned to a static Elastic IP (EIP). External third-party APIs often require you to whitelist these specific EIPs.
• Advanced Egress Control: A senior engineer knows that standard K8s network policies cannot restrict outbound traffic by domain name (e.g., blocking everything except api.stripe.com). To solve this, a 6-year veteran implements tools like Cilium (Egress Gateway) or a service mesh like Istio to enforce Layer 7 egress filtering, preventing data exfiltration if a container is compromised.

6. What Else is in the EKS Service & Networking Stack?

To interview or operate at a 6-year senior level, you must master these additional critical components of the EKS network ecosystem:

A. AWS VPC CNI Plugin (The Ground Floor)

Unlike standard vanilla Kubernetes which uses overlay networks (like Flannel), EKS uses the AWS VPC CNI. Every Pod gets a real, routable IP address directly from your AWS VPC subnet.

• The Senior Problem (IP Exhaustion): Because pods use real VPC IPs, large clusters can easily run out of IPs in a standard subnet.
• The Senior Solution: You must know how to configure Custom Networking (assigning secondary, non-routable CIDR blocks like 100.64.0.0/8 to pods) and enable Prefix Delegation (allocating /28 IP blocks to network interfaces to increase pod density per EC2 node).

B. CoreDNS & NodeLocal DNSCache

How do pods resolve domains? They hit the CoreDNS pods running in the cluster. At scale, thousands of pods spamming CoreDNS creates a massive bottleneck. Senior engineers deploy NodeLocal DNSCache, running a tiny DNS agent on every single node to cache queries locally and prevent intermittent connection timeouts.

C. Pod Identities (The Modern Security Layer)

Pods often need to talk to other AWS services (like S3 buckets or DynamoDB).

• Old way: IRSA (IAM Roles for Service Accounts) which required complex OIDC providers and trust policies.
• New standard: EKS Pod Identities. It optimizes performance and simplifies credential mapping by running an agent on the node that maps AWS IAM roles directly to K8s service accounts seamlessly.

D. AWS VPC Lattice (The Future of Cross-Cluster Mesh)

A cutting-edge DevOps engineer knows that managing traditional Service Meshes (like Istio or Linkerd) brings massive operational overhead. Amazon handles this natively via Amazon VPC Lattice using the Kubernetes Gateway API. It allows sidecar-less, fully managed service-to-service communication, traffic splitting, and IAM-level authentication across multiple distinct EKS clusters and AWS accounts.

Summary Checklist for a Senior DevOps Engineer

To deepen your understanding of how these routing mechanisms translate to real-world cloud infrastructure, this AWS Load Balancer Controller deep dive covers advanced ingress, namespace isolation, and DNS architectures natively inside EKS.