کوبرنتیز چهار مسئله شبکه دارد (مستندات Cluster Networking):

1. container ↔ container داخل یک Pod → localhost
2. Pod ↔ Pod → تمرکز اصلی CNI
3. Pod ↔ Service → Service + kube-proxy / جایگزین
4. External ↔ Service → Service / Ingress / LB

خود control plane «کابل مجازی» نمی‌کشد. runtime روی هر نود از پلاگین‌های CNI (Container Network Interface) برای ساخت/حذف اینترفیس، IPAM و اغلب سیاست امنیتی استفاده می‌کند.

این مقاله deep dive همهٔ خانواده‌های مهم CNI، تفاوت‌ها و use caseها است — با لینک به مقالات تخصصی Cilium و Kube-OVN.

CNI چیست؟

CNI مشخصات (spec) و قرارداد اجرایی است: وقتی Pod ساخته می‌شود، runtime پلاگین را صدا می‌زند تا:

• اینترفیس شبکه به namespace شبکه Pod بچسباند
• IP تخصیص دهد (IPAM)
• route / bridge / tunnel لازم را پیکربندی کند
• هنگام حذف Pod، cleanup کند

بدون CNI سازگار با مدل Kubernetes، فرض‌های پایه cluster برقرار نیست.

مدل شبکه Kubernetes (خلاصه الزامات)

چگونه این اصل پیاده شود — overlay، BGP flat، VPC ENI، OVN، eBPF — دقیقاً تفاوت CNIهاست.

لایه‌های تصمیم قبل از انتخاب برند

Overlay در برابر Underlay / L3

Overlay ساده و portable است؛ native/VPC معمولاً latency کمتر و debugging آشناتر با ابزار شبکه دیتاسنتر دارد، ولی به توپولوژی و quota وابسته است.

Datapath: iptables · IPVS · eBPF · OVS

NetworkPolicy

اگر به NetworkPolicy نیاز دارید، CNI باید enforcement داشته باشد (یا با Canal ترکیب کنید).

جدول مقایسه کلان

«همه CNIها» در اکوسیستم بیشتر از این‌اند (Kindnet، kube-router، CNI-Genie، …)؛ جدول بالا پوشش تصمیم‌های واقعی production است.

Deep Dive هر خانواده

۱. Cilium — eBPF-first

• CNCF Graduated
• شبکه + امنیت + observability روی eBPF
• CiliumNetworkPolicy با L7 (HTTP/gRPC/Kafka/DNS)
• Hubble برای flow
• جایگزینی kube-proxy، Cluster Mesh، WireGuard/IPsec
• پیش‌فرض مفهومی پشت GKE Dataplane V2

Use case: خوشه جدید با نیاز Policy مقیاس‌پذیر، observability، کاهش sidecar برای بخشی از mesh، AI/HPC که latency مهم است.

جزئیات: مقاله Cilium.

۲. Calico — L3 و Policy بالغ

• پروژه Tigera؛ بسیار رایج در production
• BGP برای advertise کردن Pod CIDR بدون overlay
• Policy غنی: NetworkPolicy + GlobalNetworkPolicy + host endpoints
• Dataplane: iptables (پیش‌فرض تاریخی) یا eBPF یا Windows HNS / VPP
• مناسب hybrid و نودهای Windows

Use case: دیتاسنتر با تیم شبکه آشنا به BGP، نیاز Policy قوی بدون اجبار به L7 eBPF، محیط‌های mixed OS.

۳. Flannel — حداقل‌گرایی

• Overlay ساده (اغلب VXLAN) یا host-gw وقتی L2 مشترک دارید
• NetworkPolicy بومی ندارد
• footprint کم؛ راه‌اندازی سریع
• پیش‌فرض بسیاری نصب‌های K3s

Use case: لابراتوار، edge سبک، CI، وقتی فقط «Podها به هم برسند» کافی است.

برای Policy روی Flannel → اغلب Canal یا تعویض به Calico/Cilium.

۴. Canal — Flannel + Calico

• شبکه از Flannel، enforcement Policy از Calico
• مسیر میانی وقتی overlay ساده می‌خواهید ولی NetworkPolicy لازم است

Use case: ارتقا تدریجی از Flannel بدون پرش کامل به Calico routing.

۵. Antrea

• مبتنی بر Open vSwitch
• NetworkPolicy + قابلیت‌های Antrea (Traceflow، …)
• پیوند طبیعی با دنیای VMware

Use case: زیرساخت vSphere/Tanzu که Antrea پشتیبانی رسمی یا تجربه تیمی دارد.

۶. Kube-OVN و OVN-Kubernetes

مقاله تخصصی: Kube-OVN.

Use case: نیاز به جداسازی شبکه شبیه cloud VPC، EIP، ACL غنی — فراتر از flat CNI.

۷. Weave Net

• زمانی راه‌حل محبوب «یک باینری و شبکه کار می‌کند»
• امروز برای greenfield معمولاً پشت Cilium/Calico قرار می‌گیرد

Use case: cluster میراث؛ برنامه مهاجرت داشته باشید.

۸. Multus CNI — چند اینترفیس

Multus یک meta-plugin است: Pod می‌تواند علاوه بر شبکه پیش‌فرض cluster، اینترفیس دوم/سوم (SR-IOV، macvlan، شبکه جدا) داشته باشد.

Pod
├── eth0 → CNI اصلی (Cilium/Calico/…)
└── net1 → Multus → SR-IOV / macvlan / …

Use case: تلکام/NFV، جداسازی data plane، GPU/storage شبکه اختصاصی.

توجه: Multus جایگزین CNI پایه نیست — آن را با یک CNI اصلی ترکیب می‌کنید.

۹. CNIهای ابری مدیریت‌شده

در cloud، محدودیت تعداد IP/ENI per node اغلب مهم‌تر از benchmark خام CNI است.

CNI و Service / kube-proxy

Service VIP را معمولاً kube-proxy یا جایگزین eBPF پیاده می‌کند.

مقاله Service: انواع Service.

NetworkPolicy — چه کسی واقعاً enforce می‌کند؟

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api

• روی Flannel خالص: این شیء ممکن است apply شود ولی اثری نداشته باشد
• روی Calico/Cilium/Antrea/OVN: enforce می‌شود
• CRDهای اضافه قابلیت فراتر از API استاندارد می‌دهند (L7، cluster-wide، FQDN، …)

هرگز فرض نکنید «YAML NetworkPolicy نوشتم پس امن است» بدون دانستن CNI.

معیارهای انتخاب (عمیق‌تر از جدول)

۱. مقیاس و تعداد Policy

با ده‌ها/صدها NetworkPolicy، مسیر eBPF (Cilium یا Calico eBPF) معمولاً پایدارتر از iptables خالص است.

۲. تیم شبکه

اگر BGP و AS و route reflector زبان روزمره تیم است → Calico BGP درخشان است.
اگر observability اپ و identity مهم است → Cilium/Hubble.

۳. سیستم‌عامل نود

Windows worker → Calico (یا مسیرهای ابری خاص) جلوتر از Cilium کلاسیک.

۴. چندمستأجری سخت

Kube-OVN / OVN یا Policy بسیار سخت + جداسازی namespace/نیاز VPC منطقی.

۵. لبه و منابع کم

Flannel یا Cilium با پیکربندی سبک؛ از OVN سنگین پرهیز کنید مگر لازم باشد.

۶. قفل ابری

روی EKS/AKS/GKE اول CNI پیشنهادی provider را بفهمید، بعد Policy addon را اضافه کنید — تعویض CNI روی cluster زنده سخت است.

درخت تصمیم عملی

فقط lab / K3s ساده بدون Policy؟
  → Flannel

Policy لازم + می‌خواهید ساده‌ترین ارتقا از Flannel؟
  → Canal یا تعویض به Calico/Cilium

خوشه جدید cloud-native، L7 policy، Hubble، kube-proxy replace؟
  → Cilium

BGP دیتاسنتر / Windows / dataplane چندگانه؟
  → Calico

VPC/subnet/EIP مانند cloud روی bare metal؟
  → Kube-OVN (یا OVN-Kubernetes در OpenShift)

چند NIC / SR-IOV؟
  → Multus + CNI اصلی

EKS و IP از VPC؟
  → VPC CNI (± Cilium/Calico برای Policy)

نصب و تعویض — واقعیت عملیاتی

• CNI معمولاً روز اول cluster انتخاب می‌شود
• تعویض CNI ≈ بازسازی شبکه نودها، downtime یا cluster جدید
• روی K3s: --flannel-backend=none --disable-network-policy سپس نصب Cilium/Calico طبق docs
• همیشه podCIDR / serviceCIDR و عدم همپوشانی با شبکه فیزیکی را چک کنید
• Dual-stack باید از ابتدا در CNI و apiserver هم‌خوان باشد

kubectl get pods -n kube-system
kubectl -n kube-system get ds,deploy | rg -i 'cilium|calico|flannel|antrea|ovn'
kubectl get networkpolicies -A

مشاهده‌پذیری و امنیت مکمل

CNI جای Secret management یا admission policy را نمی‌گیرد؛ لایه شبکه است.

اشتباهات رایج

جمع‌بندی

همه CNIهای جدی «Pod را وصل می‌کنند». تفاوت در چگونه، با چه هزینهٔ عملیاتی، چه سطح Policy، چه observability، و چه یکپارچگی با دیتاسنتر یا cloud است. برای خوشه جدید در ۲۰۲۶، کوتاه‌ترین توصیهٔ عمومی: Cilium یا Calico را با معیارهای بالا انتخاب کنید؛ Flannel را برای سادگی آگاهانه؛ OVN/Multus را وقتی نیاز شبکه‌ای خاص دارید.

قدم بعدی

1. ببینید cluster فعلی چه CNI دارد: DaemonSetهای kube-system
2. یک NetworkPolicy تستی apply کنید و واقعاً ترافیک را block کنید (یا نکنید!)
3. مقاله Cilium یا Kube-OVN را برای مسیر انتخابی عمیق بخوانید
4. روی lab، K3s+Flannel را با K3s+Cilium مقایسه کنید
5. قبل از production، محدودیت IP ابری و نیاز Windows/BGP را در چک‌لیست بگذارید

منابع

• Cluster Networking — Kubernetes
• Network Plugins
• CNI Specification
• Cilium (مقاله P30Light)
• Kube-OVN (مقاله P30Light)
• K3s networking (مقاله P30Light)
• Services (مقاله P30Light)
• Calico docs
• Flannel
• Antrea
• Multus

منتشر شده در P30Light — بخش زیرساخت و سرور.