Hello everyone! Today, I’d like to delve deeply into the architecture known as the ‘Standard’ in Kubernetes operating environments.
When you first encounter Kubernetes, you might simply expose services externally using NodePort or LoadBalancer types. But in a real production (operational) environment, why is it considered best practice to have a separate Edge Node and configure a Service Mesh internally?
I’ll explain the reasons, along with a comprehensive overview of the chronic network issues this structure resolves. 🚀
🏗️ Standard Architecture: The Meeting of Edge Node and Service Mesh
Modern Kubernetes operating environments are clearly divided into two main areas:
- Edge Node (Castle Gate 🏰): The sole entry point for external traffic.
- Service Mesh (Internal Road Network 🛣️): A secure and efficient communication network between internal services (Pods).
This structure isn’t just for aesthetics; it’s a design conceived to achieve three goals: security, stability, and visibility.
1. Clear Separation of Traffic (North-South vs East-West)
- North-South Traffic (External ↔️ Internal): This is traffic where users access our services. It is handled exclusively by the Ingress Controller (or Gateway) located on the Edge Node. This maximizes security by not directly exposing the worker nodes running actual applications to the internet.
- East-West Traffic (Internal ↔️ Internal): This is traffic where microservices exchange data with each other. The Service Mesh (e.g., Istio, Linkerd) handles this, managing complex communication logic.
2. Zero Trust Security 🛡️
“Don’t trust just because it’s inside the internal network!”
This is the core philosophy of this architecture.
- mTLS Encryption: The service mesh automatically encrypts internal communications. Even if a hacker infiltrates, they cannot eavesdrop on the data.
- Fine-grained Authorization: Policies like “Order Service can only access Payment Service” can be enforced at the infrastructure level, not just in code.
💡 Key: Solving the Chronic Problems of NodePort
A decisive reason many adopt this architecture is to solve the network inefficiencies and security issues inherent in the traditional NodePort method.
Problem 1: Does traffic bounce like a ping-pong ball? (Traffic Hop Phenomenon) 🏓
- NodePort Situation: If a client sends a request to Node A, but the actual Pod is on Node B, the traffic must travel once more from Node A → Node B via the Kubernetes internal network (kube-proxy). This causes unnecessary latency.
- Edge Node Solution (Smart Routing): The Ingress Controller on the Edge Node already knows the location of all Pods. As soon as it receives a request, it directs it straight to the node where the corresponding Pod is located. Unnecessary hops are eliminated, speeding up the process.
Problem 2: Has the client’s real IP disappeared? (Source IP Loss) 🕵️♂️
- NodePort Situation: When traffic hops between nodes (SNAT), the source IP of the packet changes to the node’s IP. If you check application logs, all requests appear to come from an internal IP, making it impossible to identify the actual user or their connection origin.
- Edge Node Solution (IP Preservation):
- L4 Level: The original IP of incoming traffic is maintained through Edge Node settings (externalTrafficPolicy: Local).
- L7 Level: When the Ingress forwards traffic to the backend, it attaches a tag in the X-Forwarded-For header, saying **”this was originally sent by this person”**. This allows the application to accurately identify the user’s real IP.
📝 Summary: Why is this the ‘Standard’?
| Category | NodePort / Simple Configuration | Edge Node + Service Mesh (Standard) |
| — | — | — |
| Security | Worker nodes exposed externally (Risk ⚠️) | Single entry point for easy defense and control (Secure 🔒) |
| Traffic Path | Hops between nodes causing latency | Optimal direct path to Pods |
| Client IP | Changed to node IP, unidentifiable | Actual IP identifiable via headers, etc. |
| Fault Tolerance | Risk of cascading failures upon error | Fault isolation and blocking with circuit breakers |
Ultimately, this architecture realizes the ideal of cloud-native: “Developers focus solely on business logic, while complex networking and security are handled automatically by the infrastructure.”
While initial setup requires some effort, considering the stability and debugging convenience in the operational phase, it’s not just an option but a necessity. What does your cluster look like now? 🤔
Leave a Reply