شبکه در Kubernetes معمولاً با یک CNI ساده شروع می‌شود: Flannel برای overlay سبک، Calico برای policy و BGP، یا Cilium برای eBPF و observability. تا وقتی cluster تک‌tenant و workloadهای stateless دارید، همین کافی است.

اما وقتی به multi-tenancy واقعی، VMهای KubeVirt با IP ثابت، اتصال مستقیم به شبکه فیزیکی (Underlay/VLAN)، VPC با فضای IP هم‌پوشان، یا NAT/EIP شبیه VM سنتی نیاز دارید — CNIهای minimal کم می‌آورند.

Kube-OVN پاسخ این gap است:

Cloud Native Network for KubeVirt and Multi-Tenancy

یعنی OVN (Open Virtual Network) و OVS (Open vSwitch) — موتور شبکه‌ای که سال‌ها در data center و OpenStack اثبات شده — را مستقیم به Kubernetes وصل می‌کند. پروژه اصلیاً توسط Alauda ساخته و در production enterprise scale شده است.

مشکل CNI پیش‌فرض Kubernetes

مدل شبکه K8s فرض می‌کند:

• هر Pod یک IP منحصربه‌فرد در cluster دارد
• همه Podها (در حد policy) با هم صحبت می‌کنند
• Service و DNS cluster-wide کار می‌کنند
• Node ↔ Pod routing شفاف است

این برای یک tenant، یک trust domain عالی است. برای IaaS داخلی، private cloud، یا VM+container hybrid نه:

Kube-OVN چیست؟

Kube-OVN یک CNI plugin و کنترل‌پلین شبکه برای Kubernetes است که:

• OVN را به‌عنوان control plane (logical switches، routers، ACLs) استفاده می‌کند
• OVS را به‌عنوان data plane روی هر node اجرا می‌کند
• مفاهیم Subnet، VPC، IPPool، Vlan، NAT Gateway را به‌صورت Kubernetes CRD expose می‌کند
• با NetworkPolicy API سازگار است (پیاده‌سازی با OVN ACL)
• IPv4، IPv6 و dual-stack را پشتیبانی می‌کند
• Overlay (Geneve/VXLAN/STT) و Underlay (VLAN) هر دو را پوشش می‌دهد

Repo: github.com/kubeovn/kube-ovn

مستندات: kubeovn.github.io/docs

معماری: چطور کار می‌کند؟

نمای کلی

                    ┌─────────────────────────┐
                    │   kube-apiserver        │
                    │   (Subnet, VPC, IP CRD) │
                    └───────────┬─────────────┘
                                │
                    ┌───────────▼─────────────┐
                    │  kube-ovn-controller    │
                    │  (تبدیل CRD → OVN NB)   │
                    └───────────┬─────────────┘
                                │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                 ▼
        ovn-central       ovn-central       ovn-central
        (NB/SB DB HA)     (replica)         (replica)
              │
    ┌─────────┴─────────┬───────────────┐
    ▼                   ▼               ▼
 Node 1              Node 2           Node N
 ovs-ovn +           ovs-ovn +        ovs-ovn +
 kube-ovn-cni        kube-ovn-cni     kube-ovn-cni
    │                   │               │
 ovn0 (join)         ovn0             ovn0
    │                   │               │
  Pods/VMs            Pods/VMs         Pods/VMs

مؤلفه‌های کلیدی

Subnet: واحد اصلی شبکه

برخلاف CNIهایی که subnet را per-node می‌بینند، در Kube-OVN Subnet یک موجودیت global است:

• IPهای یک Subnet می‌توانند روی هر node توزیع شوند
• هر Namespace می‌تواند به Subnet خاص bind شود
• Podها IP را از Subnet namespace خود می‌گیرند

سه Subnet built-in:

VPC: multi-tenancy در سطح L3

هر VPC به یک Logical Router در OVN map می‌شود:

• Subnetهای زیر یک VPC فضای IP مشترک دارند
• VPCهای مختلف کاملاً ایزوله — حتی با همان CIDR (مثلاً هر دو 10.0.1.0/24)
• ترافیک بین VPCها با Datapath ID در tunnel تفکیک می‌شود

هشدار: VPC سفارشی محدودیت دارد: NodePort، health check مبتنی بر شبکه، DNS پیش‌فرض cluster و دسترسی Node به Pod در custom VPC پشتیبانی نمی‌شود. برای اکثر workloadهای K8s معمولی، default VPC + NetworkPolicy/ACL کافی است.

ویژگی‌های اصلی (از kube-ovn.io)

چرا Kube-OVN؟ (use caseهای واقعی)

۱. Private Cloud / IaaS داخلی

سازمان‌هایی که Kubernetes را به‌عنوان پلتفرم self-service می‌فروشند (تیم A، تیم B، مشتری داخلی) به VPC نیاز دارند — نه فقط Namespace که isolation نرم است.

Tenant A (VPC-1)          Tenant B (VPC-2)
10.0.0.0/16               10.0.0.0/16   ← همان CIDR، بدون تداخل
├── ns: billing           ├── ns: analytics
└── ns: api               └── ns: ml

۲. KubeVirt + VMهای Cloud-Native

KubeVirt VM را به Kubernetes می‌آورد؛ اما شبکه VM (static MAC/IP، L2، SR-IOV) با CNI ساده سخت است.

Kube-OVN + KubeVirt این قابلیت‌ها را اضافه کرده:

• IP ثابت برای VM
• VPC per tenant برای VMهای مختلف
• SR-IOV و OVS-DPDK برای performance
• مدیریت شبکه مثل data center سنتی — از طریق CRD

۳. Underlay برای workload حساس به latency

Overlay (Geneve/VXLAN) overhead encapsulation دارد. برای database، storage، HPC، یا AI training که throughput شبکه critical است:

• Pod مستقیماً IP از range فیزیکی می‌گیرد
• VLAN به switch upstream bind می‌شود
• latency و throughput نزدیک bare-metal

۴. خروجی با IP ثابت (compliance / whitelist)

با centralized gateway یا VPC NAT Gateway:

• همه Podهای یک Subnet از یک IP مشخص به اینترنت می‌روند
• audit، firewall whitelist و compliance ساده‌تر می‌شود

۵. ایزوله‌سازی Subnet (micro-segmentation)

spec:
  private: true
  allowSubnets:
    - 10.16.0.0/16   # فقط default subnet می‌تواند وصل شود

مناسب DMZ داخلی، sandbox امنیتی، یا جداسازی PCI scope.

۶. Multi-Cluster L3

شعبه‌ها یا regionهای مختلف را در یک fabric L3 منطقی — بدون VPN دستی per service.

۷. Mirror و troubleshooting

Traffic mirror برای IDS، packet capture و replay — rare در CNIهای سبک.

مقایسه با CNIهای رایج

Kube-OVN برنده نمی‌شود وقتی: cluster کوچک dev، تیم networking experience کم، یا فقط HTTP microservice ساده دارید — Flannel/Calico ساده‌ترند.

Kube-OVN برنده می‌شود وقتی: multi-tenant، hybrid VM+container، underlay، یا networking شبیه OpenStack/AWS VPC می‌خواهید.

پیش‌نیازها

قبل از نصب (Prerequisites):

• Kubernetes ≥ 1.21 (توصیه: 1.26+)
• Linux kernel با ماژول‌های openvswitch، geneve/vxlan
• kubectl با دسترسی cluster-admin
• هم‌خوانی POD_CIDR، SVC_CIDR و service-cluster-ip-range apiserver
• برای Underlay: switch با VLAN trunk و planning IP فیزیکی
• برای VPC NAT Gateway: Multus-CNI

نصب

روش ۱: اسکریپت one-click (production)

از One-Click Installation:

# دانلود نسخه stable
curl -fsSL https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.16/dist/images/install.sh -o install.sh

# ویرایش متغیرهای کلیدی:
# REGISTRY="docker.io/kubeovn"
# VERSION="v1.16.2"
# POD_CIDR="10.16.0.0/16"      # نباید با SVC/NODE/JOIN overlap داشته باشد
# SVC_CIDR="10.96.0.0/12"      # هم‌خوان با --service-cluster-ip-range
# JOIN_CIDR="100.64.0.0/16"    # ارتباط Pod ↔ Node
# TUNNEL_TYPE="geneve"         # geneve | vxlan | stt
# IFACE=""                     # NIC فیزیکی؛ خالی = auto-detect

chmod +x install.sh
bash install.sh

اسکریپت deploy می‌کند:

• ovn-central (HA روی control-plane nodes)
• kube-ovn-controller
• ovs-ovn و kube-ovn-cni روی هر node
• Subnetهای ovn-default و join

روش ۲: Helm

helm repo add kubeovn https://kubeovn.github.io/kube-ovn/
helm repo update

# حتماً values را قبل از install تنظیم کنید — upgrade بدون values ممکن است config را reset کند
helm install kubeovn kubeovn/kube-ovn \
  --namespace kube-system \
  --version v1.16.2 \
  --wait \
  -f values.yaml

تأیید نصب

kubectl get pods -n kube-system | grep -E 'ovn|kube-ovn'
kubectl get subnet
# NAME          PROTOCOL   CIDR            PRIVATE   NAT     DEFAULT
# join          IPv4       100.64.0.0/16   false     false   false
# ovn-default   IPv4       10.16.0.0/16    false     true    true

پیکربندی عملی

ساخت Subnet سفارشی برای Namespace

از Config Subnet:

apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: app-subnet
spec:
  protocol: IPv4
  cidrBlock: 10.66.0.0/16
  excludeIps:
    - 10.66.0.1..10.66.0.10
  gateway: 10.66.0.1
  gatewayType: distributed   # یا centralized برای IP خروجی ثابت
  natOutgoing: true
  namespaces:
    - production
    - staging

kubectl create ns production
kubectl run nginx --image=nginx:alpine -n production
kubectl get pod -n production -o wide
# IP از 10.66.0.0/16

Gateway متمرکز (egress IP ثابت)

spec:
  gatewayType: centralized
  gatewayNode: "worker-1,worker-2"
  natOutgoing: true
  enableEcmp: true   # از v1.12+ — load balance بین gateway nodes

Static IP برای Pod

apiVersion: v1
kind: Pod
metadata:
  name: db-primary
  annotations:
    ovn.kubernetes.io/ip_address: "10.66.0.50"
    ovn.kubernetes.io/mac_address: "00:00:00:AA:BB:CC"
spec:
  containers:
    - name: postgres
      image: postgres:16

Bind Pod به Subnet خاص

metadata:
  annotations:
    ovn.kubernetes.io/logical_switch: app-subnet

برای Deployment: annotation را در spec.template.metadata.annotations بگذارید.

VPC multi-tenant

از VPC Introduction:

apiVersion: kubeovn.io/v1
kind: Vpc
metadata:
  name: tenant-a
spec:
  namespaces:
    - team-a
---
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: tenant-a-net
spec:
  vpc: tenant-a
  cidrBlock: 10.0.1.0/24
  protocol: IPv4
  namespaces:
    - team-a

# tenant-b — همان CIDR، VPC جدا
apiVersion: kubeovn.io/v1
kind: Vpc
metadata:
  name: tenant-b
spec:
  namespaces:
    - team-b
---
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: tenant-b-net
spec:
  vpc: tenant-b
  cidrBlock: 10.0.1.0/24
  protocol: IPv4
  namespaces:
    - team-b

Pod در team-a و team-b هر دو 10.0.1.x می‌گیرند ولی به هم ping نمی‌زنند.

Subnet ACL (فایروال L3/L4)

spec:
  acls:
    - action: drop
      direction: to-lport
      match: ip4.dst == 10.10.0.2
      priority: 1002
    - action: allow-related
      direction: from-lport
      match: ip4.src == 10.10.0.2
      priority: 1002

از ترکیب هم‌زمان NetworkPolicy + Subnet ACL + Security Group خودداری کنید — همه روی OVN ACL پیاده شده و priority conflict ممکن است.

NetworkPolicy

Kube-OVN NetworkPolicy API استاندارد Kubernetes را با OVN ACL پیاده می‌کند — نیازی به تغییر manifest معمولی نیست:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

عملیات و troubleshooting

kubectl-ko

ابزار رسمی diagnostic:

# نصب plugin
# (معمولاً با install.sh در PATH قرار می‌گیرد)

kubectl ko nbstatus    # وضعیت Northbound DB
kubectl ko sbstatus    # وضعیت Southbound DB
kubectl ko trace <pod> <target-ip>   # trace مسیر packet
kubectl ko diagnose    # health check جامع

لاگ‌های مفید

مشکلات رایج

Kube-OVN در stack مدرن

┌──────────────────────────────────────────────────────┐
│                  Kubernetes API                       │
├──────────────┬───────────────┬───────────────────────┤
│  Workloads   │   KubeVirt    │   Network CRDs        │
│  (Pods/Dep)  │   (VM/VMI)    │ Subnet/VPC/IP/Vlan    │
└──────┬───────┴───────┬───────┴───────────┬───────────┘
       │               │                   │
       └───────────────┼───────────────────┘
                       ▼
              kube-ovn-controller
                       │
         ┌─────────────┴─────────────┐
         ▼                           ▼
    OVN (logical)              OVS (physical)
    routers/switches/ACLs      per-node datapath
         │                           │
         └──────── overlay/underlay ─┘
                       │
              Physical network / Internet

الگوی رایج: default VPC برای workloadهای K8s معمولی + custom VPC برای tenantهای IaaS یا VMهای KubeVirt.

چه زمانی Kube-OVN نگذارید؟

• Cluster dev/test با چند Pod — overkill
• تیم فقط با kubectl apply آشناست، networking engineer ندارید
• فقط به eBPF observability نیاز دارید — Cilium ساده‌تر است
• custom VPC می‌خواهید ولی به NodePort / CoreDNS cluster وابسته‌اید — محدودیت VPC را بپذیرید یا default VPC + policy استفاده کنید
• Underlay بدون هماهنگی با تیم network — VLAN conflict گرفتار می‌شوید

جمع‌بندی

اگر Kubernetes را به‌عنوان زیرساخت cloud داخلی می‌بینید — نه فقط orchestrator container — Kube-OVN یکی از کامل‌ترین CNIهای Open Source برای «شبکه enterprise در قالب cloud-native» است. پیچیدگی بالاتری دارد، اما همان قابلیت‌هایی را می‌دهد که در OpenStack Neutron یا AWS VPC سال‌ها استفاده کرده‌اید.

قدم بعدی

1. روی staging cluster با install.sh نصب کنید
2. kubectl get subnet و یک Pod تست در default subnet
3. یک Subnet + Namespace سفارشی بسازید
4. اگر KubeVirt دارید: VPC + static IP برای یک VMI تست کنید
5. kubectl ko diagnose را در runbook عملیات قرار دهید

منابع:

• Kube-OVN — Official Site
• Documentation (v1.16.x)
• One-Click Installation
• Config Subnet
• VPC Introduction
• KubeVirt + Kube-OVN
• GitHub — kubeovn/kube-ovn

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