Kubernetes网络模型、插件与网络策略的区别及适用场景
Great question—Kubernetes networking is notoriously confusing thanks to overlapping terminology and vendor-specific shorthand. Let’s break down these three core concepts clearly, and address that Calico terminology mix-up you noticed.
1. Network Model: The Rulebook
First, the network model is Kubernetes' official set of requirements that all cluster networking must follow. It’s not a tool—it’s a blueprint to ensure consistent communication across pods, nodes, and external services. The three non-negotiable rules are:
- All pods can communicate with each other without NAT (within the cluster)
- All nodes can communicate with all pods without NAT
- A pod sees its own IP address the same way other pods see it
Use case: This is the foundation—every network implementation in Kubernetes must adhere to this model. There’s no "choosing" a model; you’re bound by it by virtue of using Kubernetes. It ensures your workloads behave predictably regardless of which tool you use to build the network.
2. Network Plugin: The Implementation Tool
A network plugin is the actual software that builds and manages the network to meet the Kubernetes network model’s requirements. Tools like Calico, Flannel, Cilium, and Weave Net are all plugins. They handle the heavy lifting: assigning pod IPs, configuring routing between nodes, handling cross-node pod communication, and more.
Why separate model and plugin?
Your confusion here is totally valid—why split the rulebook from the tool? The answer is flexibility. Kubernetes only defines what needs to work, not how to make it work. This lets you pick a plugin that fits your cluster’s specific needs:
- A small, simple cluster might use Flannel (lightweight, easy to set up)
- A large, production cluster needing traffic control might use Calico
- A performance-critical cluster might use Cilium (leveraging eBPF for fast routing and filtering)
Use case: Choose a plugin based on your cluster size, performance needs, and whether you require extra features like network policy support (more on that next).
3. Network Policy: The Traffic Firewall
Network policies are Kubernetes resources that let you control traffic flow at the IP address or port level—think of them as cluster-wide firewalls for your pods. They’re optional, but only work if your network plugin supports them (Flannel doesn’t by default, while Calico and Cilium do).
Addressing the Calico terminology mix-up
You’re right to suspect Azure’s terminology is off here. Kubernetes docs don’t list Calico as a "network model"—that’s likely a wording error. Calico is a network plugin that fully implements the Kubernetes network model, and it also includes support for network policies. Azure probably shorthanded it as a "network policy" because many users adopt Calico specifically to enable network policy enforcement, but that’s not technically accurate.
Use case: Use network policies when you need to lock down traffic:
- Isolate production pods from test pods in separate namespaces
- Restrict access to a database pod to only your application pods
- Block external IPs from accessing sensitive internal services
Quick Recap of Relationships
- Network Model: The mandatory rules all cluster networking must follow
- Network Plugin: The tool that implements those rules
- Network Policy: An optional layer on top of the plugin to control traffic flow
内容的提问来源于stack exchange，提问作者Matthias M
