Kubernetes deconstructed: how it works, from pods to the control plane

Overview

This first part of the talk introduces the presentation "Kubernetes Deconstructed: Understanding Kubernetes by Breaking It Down" by Carson Anderson from DOMO. It covers basic user concepts in Kubernetes, walking through containers, pods, deployments, services, and ingress rules before demonstrating how to create them using kubectl.

0:00 Introduction

• Speaker: Carson Anderson, DOMO
• GitHub: @carsonoid (where full source code and presentation can be found)
• Goal: Provide a high-altitude "flight" over the landscape of Kubernetes, peeling back the layers to understand how everything fits together.

1:17 Kubernetes for the End User: Containers to Pods

• Containers: An application is just a file system packed into a box with metadata for runtime and labels for identification.
• Problem with single containers: Often you want to run things together tightly coupled (e.g., an application alongside a Prometheus exporter or an Envoy sidecar, plus volume data). Docker doesn't provide low-level tools for this.
• Pods: Kubernetes solves this with a Pod, which encapsulates:
  • A container
  • Multiple containers
  • A container and a volume
  • Any combination of these. Pods are what Kubernetes executes.

2:36 Deployments, Services, and Ingress

• Deployments: Running multiple pods manually doesn't provide fault tolerance or load balancing. A Deployment manages creating pods, replicas, and labeling them.
  • Diagram elements shown on screen:
    • Deployment: Has selector: app=kube-decon, tier=web and image: carsonoid/kube-decon:v1.
    • Spawns pods like kube-decon-v1-1 and kube-decon-v1-2.
• Services: To access the application inside the cluster, Kubernetes uses a Service pointing at the pods, reachable via service IP or name. Updating the deployment image cycles out pods automatically.
• Ingress: To route traffic from outside the cluster into the cluster, Ingress rules define how incoming requests to a pre-defined load balancer and hostname map to internal services and ports.

3:57 Creating Resources with kubectl

• Namespace creation:

  $ kubectl create namespace kube-decon
  

• Declarative Configuration (YAML):
  • The deployment YAML defines the app, replicas, and container port:

    apiVersion: apps/v1beta2
    kind: Deployment
    metadata:
      name: kube-decon
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: kube-decon
          tier: web
      template:
        metadata:
          labels:
            app: kube-decon
            tier: web
        spec:
          containers:
          - name: kube-decon
            image: carsonoid/kube-decon:latest
            ports:
            - containerPort: 2015
    

  • The service YAML uses load balancing, discovery, and abstraction, listening on port 80 and targeting the backend port:

    kind: Service
    apiVersion: v1
    metadata:
      name: kube-decon
    spec:
      selector:
        app: kube-decon
        tier: web
      ports:
      - protocol: TCP
        port: 80
        targetPort: 2015
    

  • The ingress rule YAML maps external hostnames and paths to the service:

    # (Ingress rule configuration mapping hostnames and paths to services)
    

• Workflow: Send these files to Kubernetes using kubectl, and it returns the requested deployment, service, and ingress resources.

5:00 Creating Resources with kubectl (Continued)

The instructor continues explaining the resource creation process using kubectl and autocompletion:

• Configure the master address, credentials, and context to tie them together.
• Use context to switch between clusters easily.

To create the resources simply, imperatively create the namespace and then throw YAML files at it one at a time:

Create Resources
  - Create a namespace for the project
    `kubectl create namespace kube-decon`
    namespace "kube-decon" created
  - Create the pods via a deployment
    `kubectl --namespace kube-decon create -f resources/basic/kube-decon-deployment.yaml`
    deployment "kube-decon" created
  - Expose the pods via a service
    `kubectl --namespace kube-decon create -f resources/basic/kube-decon-service.yaml`
    service "kube-decon" created
  - Route a hostname to the service via ingress
    `kubectl...`

Terminal status check:

$ kubectl --namespace kube-decon get deployment,pods,service,ingress
NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/kube-decon     2         2         2            2           9s

NAME                        READY     STATUS    RESTARTS   AGE
po/kube-decon-6f9457c74-87hbh   1/1     Running   0          9s
po/kube-decon-6f9457c74-mg4m   1/1     Running   0          9s

NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
svc/kube-decon          ClusterIP   172.28.96.199    <none>        80/TCP    9s

NAME                  HOSTS                                  ADDRESS   AGE
ing/kube-decon        kube-decon.kubecon.carson-anderson.com           8s

5:58 The Meat: Extending and Configuring Kubernetes

Slide shown: Three hexagonal icons labeled Replacement, Plugin, and Config.

• Cluster Admin view: The instructor points out that the symbols scattered across the slides represent places where you can replace, extend, and highly configure Kubernetes.
• Kubernetes is built to be extended upon.

6:23 Center Files to Kubernetes: The Control Plane Components

Slide shown: A list of master and node components:

kube-apiserver
kube-scheduler
kube-controller-manager
kubelet
kube-proxy

• The top three are master components; the bottom two are primarily node components (though they can run on the masters).
• Almost everything in Kubernetes is pluggable, replaceable, and configurable (e.g., kubelet can be replaced by rocketlet).

6:54 kube-apiserver and Etcd

Slide shown: A plug icon labeled CustomResourceDefinitions and apiserver-aggregation.

• When files are sent into the API and things are retrieved, that is the API server.
• Extensions: Custom Resource Definitions (CRDs) and API server aggregation.
• Storage: Resources do not live in the ether; they live in Etcd (or an Etcd cluster more commonly).
• A lot of the power and reactivity of Kubernetes comes from Etcd features surfaced up through the API.

7:40 kube-scheduler

Slide shown: An oval loop labeled Watch.

• Analogy: The scheduler is the maitre d' of Kubernetes.
• Mechanism (Watch): It hooks up to the API server with a "long watch." This is a pub/sub event model. Instead of listing and checking for differences constantly, the scheduler tells the API server: "Hey, I'm subscribed to all of these; tell me about it, and I'll react instantly."
• The scheduler sits in the restaurant, receives incoming pods and tables, and decides who sits where.

Slide shown (Configuring Scheduler):

affinity/anti-affinity
nodeSelector
taints/tolerations
reservations/limits

• Custom Schedulers: You can write your own custom scheduler in just a few lines of bash or code if you need scheduling decisions based on outside information the regular scheduler doesn't know about.
• Both: You can also run the standard Kubernetes scheduler for default pods and assign specific schedulers per pod.

9:13 kube-controller-manager

Slide shown: The "brain" of Kubernetes.

• If the API server is the heart, the controller manager is the brain. It made all the resources. If you poke around in the API, you notice you only made a couple of things, but tons of other stuff got created automatically.
• Controllers in charge: Just like a real-life manager, the controller manager doesn't do any work itself—it's in charge of the guys that do the work.
• Inside the controller manager, there are way more than three core control loops that sit there and watch to make specific logic happen.
• Operators / Custom Controllers: You can build custom controllers (the operator pattern), which is even easier now with the meta-controller, almost always paired with Custom Resource Definitions.

10:00 Kubernetes Control Plane Controllers

All of the controllers talk to a bunch of things in the API. It is not a one-to-one relationship; there are lots of connections.

+-------------------+      +-------------------------------+
|  kube-apiserver   |      |    kube-controller-manager    |
+-------------------+      +-------------------------------+
|  namespaces       | ---> | Watch namespace-controller    |
|  deployments      | ---> | Watch deployment-controller   |
|  replicasets      | ---> | Watch replicaset-controller   |
|  pods             |      | Watch V                       |
|  services         |      +-------------------------------+
|  secrets          |
|  ingresses        |
+-------------------+

• All controllers are watching and making things happen. These are the proactive parts of Kubernetes.
• For example:
  1. A user creates a namespace.
  2. A controller makes the service account.
  3. Another controller makes a secret.
  4. A user makes a deployment.
  5. A controller makes a replica set.
  6. Another controller makes nodes.
  7. A user makes a service.
  8. A controller makes an endpoints object and points it at the pods. (Endpoints are the actual routing meat of services).

When you say Kubernetes "did something for me", it is a controller in the controller manager that did that. With advanced logging and using RBAC extensively, you can get really cool logs that say exactly which piece did what action to all your resources.

11:00 Node Components: Kubelet and Kube-proxy

+----------------------------------------------------------+
|                      kube-apiserver                      |
+----------------------------------------------------------+
      | Watch                           | Watch
      v                                 v
+------------------+            +------------------+
|     kubelet      |            |    kube-proxy    |
+------------------+            +------------------+
         |                              |
         v                              v
+--------------------------------------------------+
|                       node                       |
|              +--------------------+              |
|              |        pod         |              |
|              | kube-decon-2035... |              |
|              +--------------------+              |
|                   kube-node-02                   |
+--------------------------------------------------+

Kubelet's Job

• Hooks up to the API server like everything else does.
• Its job is to live on every single node and make containers real.
• It watches the API server: "Oh, I'm on this node, you have this pod that's scheduled there. The etcd said go sit there. Somebody has to make it real." That is the Kubelet.
• It talks to your container runtime (Docker, rkt, or any standard runtime interface) to create the pod and make the container real.
• It also does cool things like liveness probes (checking if your process is running—which doesn't mean you are alive) and readiness checks (are you ready to receive traffic?).
• It constantly checks up on these containers and reports information back up to the API server.

Kube-proxy's Job

• Talks to the API server and connects to the veins.
• Makes services real. It is constantly watching for all services, and on every node, every single service is made real all the time by kube-proxy.
• If something changes about the underlying service (a pod behind it changes or goes away), kube-proxy makes it real; a new one comes in, kube-proxy makes it real. That is its whole job.
• You can completely swap out kube-proxy entirely. Different network providers and load balancing companies do this (some do it with just Linux kernel features).

12:38 Kubernetes Networking for the Network Admin

+----------------------------------------------------------+
|              Kubernetes for the Network Admin            |
+----------------------------------------------------------+

To understand how things talk to each other:

+-----------------------+
|          pod          |
|    kube-decon-v2-1    |
+-----------------------+
|  IP      10.255.8.18  |
+-----------------------+
|      kube-node-01     |
+-----------------------+
|  pod cidr  10.255.0.0 |
+-----------------------+

Pod IPs and CIDRs

• Every pod in Kubernetes as a fundamental tenant has a unique IP. That pod is unique across the entire cluster.
• Pods live on nodes because they are containers and have to run somewhere.
• Nodes have a unique IP across the entire cluster.
• Nodes have a pod CIDR range that says "here is all the range that any pod on me has to be in" (mostly for routing reasons). This can change entirely based on the network provider, but the default gives a big chunk of a larger range.

13:30 Network Providers

To be a valid network provider in Kubernetes, you must check three boxes:

1. All containers can communicate with all other containers without NAT.
   • All containers/pods communicate with all other without NAT. They use containers interchangeably straight from the docs.
   • It's flat. You just need to be able to get from everything to everything directly.
   • If this scares you as a security person, do not worry — solutions for that exist in the power user section, but this is the network architecture. It is very flat.

[pod (kube-decon-1)] <---> [pod (kube-decon-2)]
        ^                        ^
        |                        |
        v                        v
[pod (kube-decon-3)] <---> [pod (kube-decon-4)]

2. All nodes can communicate with all containers (and vice-versa) without NAT.

   • Nodes, pods, flat. Everything just talks to everything.

3. The IP that a container sees itself as is the same IP that others see it as.

   • Don't mung your IPs. Don't let me think I'm sitting somewhere and everyone else thinks I'm somewhere else; it's very confusing. Keep it simple.
   • Mostly, according to the docs, this is done to make it easier to go from a VM architecture to a pod architecture.

15:00 Kubernetes Services and ClusterIP

• Moving from pods to services.
• A service has a selector pointing to a subset of pods, and at least one port (front-end port and back-end port can be different due to abstraction and load balancing).
• Multiple services can exist; they must have unique listening ports, but can forward to the same port on the back-end.

Slide diagram for a service:

┌──────────────────────────────────────────────┐
│                   service                    │
│                  kube-decon                  │
├──────────────────────────────────────────────┤
│ selector  app=kube-decon, tier=web           │
├──────────────────────────────────────────────┤
│ port      80:2015                            │
└──────────────────────────────────────────────┘

• Services have a type. There are four types of services (the three big ones are covered here).
• Creating a service (explicitly or implicitly) assigns it a ClusterIP.
• A controller and controller manager assigns the ClusterIP to the service.

Example scenario:

• Web server pods (www-1, www-2) and a cache pod (cache-1).
• Pointing web servers straight to the cache IP works, but is "flat" and fragile (if the cache pod goes away or you scale up, you have to reconfigure).
• Using a ClusterIP service: point web servers at the ClusterIP service, which sits in front of the cache pods. The ClusterIP never changes.

Service naming and DNS:

• DNS addon in Kubernetes is optional but highly recommended.
• You can use service names, namespace specifications, and full cluster qualification.
• IPs are used because everything resolves down to that.

17:00 How Service Hops Work: iptables and kube-proxy

• Pods live on nodes, but the ClusterIP does not. If you check every machine/node in the cluster, you will never find that ClusterIP address on any interface.
• It is a target for iptables rules (with default networking).
• iptables says: traffic coming out of here destined for that IP gets randomly assigned to the active pods behind it.
• kube-proxy is the component that watches services and endpoints, and makes those iptables rules real. When something changes in the API server, kube-proxy updates the rules.

17:52 NodePort Services

• ClusterIP is great inside the cluster (pod-to-pod), but communication needs to come from the rest of the infrastructure.
• NodePort builds on ClusterIP. It still gets a ClusterIP, but it also gets a NodePort.
• The NodePort comes from a high port range, managed by the controller manager.

Slide diagram for a NodePort service:

┌──────────────────────────────────────────────┐
│                   service                    │
│                     WWW                      │
├──────────────────────────────────────────────┤
│ selector  app=website, tier=www              │
├──────────────────────────────────────────────┤
│ port      31579:80:80                        │
├──────────────────────────────────────────────┤
│ clusterIP 10.0.15.45                         │
├──────────────────────────────────────────────┤
│ type      NodePort                           │
└──────────────────────────────────────────────┘

• NodePort uses iptables to create another entry point into the same iptables rules used for pod-to-pod communication, except the NodePort is available from anywhere else that can reach the nodes.
• Clients can point to any node's IP and the NodePort, and get load-balanced.
• However, pointing clients directly to node ports is considered "ugly" for production use.

18:54 LoadBalancer Services

• The LoadBalancer type service is cloud-specific (though the other two are always present).
• The controller manager (where the real brain action happens) sees the LoadBalancer service, talks to the cloud provider, creates a load balancer, and points it at the NodePort.
• Clients point to the load balancer, which traverses in through a normal node port (which can be static and not change), routing to all nodes as they scale up and down.
• Kubernetes makes and provisions these load balancers for you, though you can also just make NodePorts and manage load balancers yourself.

20:00 Kubernetes Control Plane Components Placement and HA

In big environments, components are separated out for security and safety, unlike a swarm setup.

+-------------------------------------------------+
|                 kube-apiserver                  |
+-------------------------------------------------+
|                 kube-scheduler                  |
+-------------------------------------------------+
|             kube-controller-manager             |
+-------------------------------------------------+
|                     kubelet                     |
+-------------------------------------------------+
|                    kube-proxy                   |
+-------------------------------------------------+

  +-----------------------+     +-----------------------+
  |        Master         |     |        Master         |
  |  +-----------------+  |     |  +-----------------+  |
  |  | kube-apiserver  |  |     |  | kube-apiserver  |  |
  |  +-----------------+  |     |  +-----------------+  |
  |                       |     |                       |
  |      node-master-01   |     |      node-master-02   |
  +-----------------------+     +-----------------------+

• kube-apiserver: Runs everywhere. This is not a surprise to anyone.
• kube-scheduler: Active and running on every single master all the time. They talk among themselves to their local API servers and elect a leader (saying "you are in charge"). The person in charge is the major D now, and the other two wait for him to die. If he doesn't check in, they take over his job.
• kube-controller-manager: You don't want more than one brain (that would be confusing like a stegosaurus having one in its tail). We elect a controller manager running on all the masters, but if one of them explodes, another one takes over. You only need one active at a time.
• kubelet: Runs on all nodes (a node component).
• kube-apiserver to Data Store (etcd): The API server has to talk to the data store to put data somewhere. This can be:
  • A cloud-managed or external etcd service (make etcd somewhere, let a cloud deal with it).
  • Hyper-converged (what we do): Every master runs a copy of etcd clustered amongst themselves, and each API server uses its own local copy. This gives full control over etcd and reduces the number of VMs needed.

21:41 Cluster Access, Ingress, and Network Routing

• Access: Backed by a cloud load balancer pointing at the API servers. We point our kubelet, all node components, and client libraries from outside the cluster at it.
• Inside the Cluster: Inside the cluster, going pod to API server goes straight to their private IPs through an endpoint (normal service discovery). External components or users should use load balancing and fault tolerance.

[Clients / LBs] 
       │
       ▼
[Ingress Controller (Service / Pods)]
       │
       ▼
[Cluster Back-End Services / Pods]

Ingress Rules

• Ingress rules are just rules; Kubernetes makes a reality via an Ingress Controller.
• There are many open-source Ingress controllers available on the expo floor. Rules have to be enforced, so we need a load balancer to get into them.

Ingress Deployment Patterns

• Ingress Nodes / HostPort: Set aside a subset of nodes called ingress nodes. Use a DaemonSet targeting just those nodes and create a host port mapping. This is very direct (old-school Docker port mapping: port on host goes straight to container port), but it leads to port madness (managing which ports things listen on, no two things listening on the same host port).
• NodePort Services: Get a node port, bounce into that, and then hop around from your service. The downside is you get balanced twice (double hop: node port at one end, controller bounces you again somewhere else). Most workloads are fine with this, but be aware of the double jump.

24:17 Container Essentials: Linux Kernel Namespaces

To understand Docker and Kubernetes, you need to understand Linux kernel namespaces, which are Linux's way of isolating processes.

• PID Namespace: Process ID isolation.
• MNT Namespace: File system isolation.
• NET Namespace: Network interface and port isolation.
• When you make a Docker container, you get split across all of these namespaces, but features allow you to join other containers' namespaces (e.g., sharing a network namespace with net=container:...).

25:00 Pods and How Containers Share Namespaces

• A pod is formed by taking multiple containers or processes and joining them into an existing namespace so they can share that one IP address in the entire cluster.
• cgroups (Control Groups): The Linux way to split up resources, which also provides built-in accounting and stat management stuff.
• Union File Systems: Neat way to work and save space.
• Node components include kubelet and kube-proxy running on kube-node-01.

25:33 Inside the Node: How Kubelet Runs a Pod

• The kubelet watches the API server, checking if there are pods requested on its node.
• Example pod containing:
  • nginx
  • prometheus-exporter
  • envoy
• Most clusters run Docker. When kubelet sees a pod to run, it talks to Docker.
• First, Docker creates a weird infra container (which joins the network namespace of that pod so they all share one IP address).
• If you run a docker ps on any Kubernetes node, you will get about twice as many containers running as you thought you needed.
• The infra container's entire job is simply to stay alive so you don't have to restart or recreate the pod, allowing you to always keep your address.
• CNI (Container Network Interface) handles how the IP address gets discovered.

26:48 Rocket (rkt) as an Alternative Runtime

• Rocket (rkt) is the other big alternative runtime for Kubernetes.
• Differences between using Docker and Rocket:
  • Rocket can do CNI the normal way.
  • CNI came out of Rocket, so you don't have to have the kubelet do it; it can be native.
  • The infra container goes away because Rocket's pod is native. Rocket's lowest thing is already a pod, not a container.
  • You spin it off, meaning there's no long-running daemon or Rocket thing sitting there the whole time — you kick it off and it is self-contained.
  • You can do hypervisor isolation with Rocket by annotating the pod to say, "Hey, your stage 1 (Rocket term) basically run this thing inside of a mini super lightweight VM."

27:52 Logging and Advanced Features

• kubectl logs connects all the way through to stream your data directly.
• Log drivers support Docker, support Kubernetes; you can grab metadata on your way out to tag and filter messages.

28:12 Kubernetes for the Power User Demo

• URL reference on screen:

  http://bit.do/kube-decon-power
  http://kube-decon.kubecon.carson-anderson.com/markdown
  

• The power user section is a grab bag of fun Kubernetes features added on top of a normal deployment with no code change:

  $ kubectl apply -f .
  

• Running the power demo applies the whole directory:

  deployment "kube-decon" configured
  warning: ... managed on resource created by either kubectl ...
  service "kube-decon" configured
  ingress "kube-decon" created
  namespace "kube-decon-power" created
  namespace "kube-decon-default-deny" created
  networkpolicy "kube-decon-webhelpers" created
  namespace "webhelpers" created
  deployment "nginx" created
  

29:00 Security Context and Network Policy

• SecurityContext: A feature where you can define a bunch of execution rules about runtime information for your pods and containers (things they can and cannot do). Applied at the pod layer, container layer, or both (can be different for different containers in the same pod).
• Network Policy: A way to create rules that block access to different things if you are scared of a flat network architecture.
  • Uses labels and YAML.
  • Policy is just rules; you need something on top that enforces network policy (options exist to read and make them happen).
  • You can define that pods with specific labels can only talk to pods with specific labels on specific ports, locking things down in a reactive way decoupled from the network model.

30:00 ConfigMaps and Secrets as Volumes

• ConfigMaps / Secrets: Key-value data pairs (ConfigMaps and secrets are handled a little differently, but that is all they are).
• Mounting: You can mount them through to your containers as volumes.
• Live Refresh: The markdown/volume shown on screen is from a ConfigMap. If you change that ConfigMap, in about a minute it will change, and you do not even have to restart the pods because it is refreshed live.
• Environment Variables: You can also take those same key-value pairs and put them into environment variables, so your Docker images that expect that as configuration will work just fine.

30:45 Affinity

• Advanced Scheduling Feature: Tells Kubernetes how pods relate to each other.
• Hard Affinity: Says, "Here's how these pods relate to each other; I want this pod to always be scheduled next to this pod." No matter where you put it, if one is there, put the other one there—tightly coupled, put them right together all the time. It gives extra information to the scheduler to tell it what you want. It won't move them around, but it will always make sure that if one's there, the other's there.
• Loose Affinity: "Try to, but I don't care if you have to split it up"—and you can wait that even.
• Node Affinity: The same thing for nodes; this pod has to be on a node like this, or try to put a pod on a node like this. Useful if you have workloads that have to use like GPUs where you would say you have to be somewhere with a GPU, you're not going to work.

31:25 Anti-Affinity

• Opposite of Affinity: Where you have hard and soft things that don't like each other.
• Pairing: Usually they are paired, so you'll see anti-affinity. For example, if you have like a GPU node, you'd want hard affinity for your GPU workloads and hard anti-affinity for your non-GPU workloads, so you just reserve that.

31:39 Summary and Presentation Tools (Sozi)

• Summary: Power user section covers User, Cluster, Network, Cloud, Linux, Power.
• Presentation Software: Used Sozi (@senshu, available at http://sozi.baierouge.fr/). It is open source; you make an SVG, you can animate every layer independently, and it just spits out web server files. If you like Prezi, but you don't want to pay for it (since everyone here is open source), or you want really hard control, you just make an SVG—it is very cool, and it can be as hard or easy as you want it to be.

32:10 Credits and Questions

• Image Credits: All the logos used are properties of their respective companies. OpenClipArt was immensely helpful in all of the art and the diagrams. The speaker stole a lot of this and altered it, and highly recommends using or contributing to it.
• Links & Resources on screen:

Full Video:  http://bit.do/kube-decon-full
Basic:       http://bit.do/kube-decon
Power:       http://bit.do/kube-decon-power
GitHub:      @carsonoid

• Q&A: The speaker invites questions from the audience, notes that the video will be up soon (the editing team is finishing it, and the placeholder link will always point to the right one even if redirected), and thanks everyone for coming.

Key Takeaways

• Core User Concepts: Kubernetes uses a hierarchy of basic objects—starting from individual containers, grouping them into multi-container Pods, scaling them via Deployments, routing internal traffic through Services, and managing external traffic with Ingress rules.
• Declarative Workflows: Using kubectl and YAML files allows users to declaratively define and deploy namespaces, applications, services, and routing rules to clusters.
• Extensible Control Plane: The Kubernetes control plane is composed of pluggable and replaceable master components (kube-apiserver, kube-scheduler, kube-controller-manager) and node components (kubelet, kube-proxy) built around a reactive pub/sub "watch" model tied to etcd.
• Controller-Driven Automation: The controller-manager acts as the "brain," running background loops that automatically provision supporting infrastructure (like replica sets, endpoints, and secrets) in response to user actions.
• Flat Cluster Networking: Kubernetes network providers require a flat network architecture where every pod and node has a unique cluster IP and can communicate directly with anything else without NAT.
• Flexible Service Routing: Services utilize iptables and kube-proxy to handle internal traffic (via ClusterIP), expose high ports across nodes (via NodePort), or provision cloud infrastructure (via LoadBalancer).
• Linux Kernel Isolation: Pods leverage underlying Linux kernel namespaces (PID, MNT, NET) and cgroups to isolate and securely share resources, with runtimes like Docker utilizing "infra containers" to maintain shared network states.
• Power User Features: Advanced Kubernetes features—such as live-refreshing ConfigMaps/Secrets, SecurityContexts, Network Policies, and Affinity/Anti-Affinity rules—allow users to tightly govern pod security, scheduling behavior, and resource relationships without changing application code.