راهنمای جامع Networking در Kubernetes با تمرکز بر Calico

بخش ۱: مدل شبکه‌ای Kubernetes (پیش‌نیاز)

قبل از Calico باید سه لایه شبکه در کوبرنتیز رو بشناسیم:

1. Pod Network — هر Pod یک IP یکتا از یک CIDR کلاستری می‌گیره (مثلاً 10.244.0.0/16). این کار CNI Plugin (مثل Calico) هست.
2. Service Network — هر Service یک ClusterIP مجازی از یک CIDR دیگه می‌گیره (مثلاً 10.96.0.0/12) که هیچ اینترفیس واقعی‌ای نداره؛ فقط با DNAT به Pod IP ترجمه می‌شه. این کار kube-proxy (یا معادلش در eBPF) هست.
3. Node Network — شبکه فیزیکی/زیرساختی که نودها روش صحبت می‌کنن.

Calico در واقع دو کار انجام می‌ده:

• CNI plugin: اختصاص IP به Pod و برقراری مسیر (Routing) بین نودها
• Network Policy Engine: اعمال قوانین فایروال بین Podها (که خود kubelet/kube-proxy این کار رو نمی‌کنن)

بخش ۲: معماری کامپوننت‌های Calico

معماری کلی به این شکل هست:

1Kubernetes API / etcd  <---sync--->  confd  --config-->  BIRD (BGP)
2        ^                                                    |
3        |                                                    v
4     Typha (اختیاری، کلاسترهای بزرگ)                   Routing Table نود
5        ^
6        |
7      Felix  --برنامه‌نویسی-->  iptables / IPVS / eBPF  (Data Plane واقعی)

نکته مهم: Felix سیاست‌گذار (Policy Engine) هست، BIRD مسیریاب (Router) هست. این دو کاملاً مستقل از هم کار می‌کنن؛ حتی می‌تونی BGP رو کامل خاموش کنی (مثلاً روی VXLAN) ولی Felix همچنان Policy رو اعمال می‌کنه.

بخش ۳: Data Plane سرویس‌ها — iptables vs IPVS (مربوط به kube-proxy)

این دو مود مربوط به kube-proxy هستن، نه مستقیماً Calico، ولی چون همیشه با هم قاطی می‌شن توضیح می‌دم:

iptables mode (پیش‌فرض تاریخی)

• به ازای هر Service و هر Endpoint، یک سری Chain در iptables (KUBE-SERVICES, KUBE-SVC-xxx, KUBE-SEP-xxx) ساخته می‌شه.
• جستجوی قانون به صورت خطی (Linear/Sequential) هست؛ یعنی با هزاران Service، پکت باید هزاران قانون رو رد کنه → تأخیر و مصرف CPU بالا می‌ره.
• DNAT با احتمال تصادفی (--probability) بین Endpointها انجام می‌شه (Round-robin واقعی نیست).

IPVS mode

• از ماژول کرنل ip_vs استفاده می‌کنه که یک Load Balancer واقعی داخل کرنل هست.
• جستجو با Hash Table انجام می‌شه → عملکرد O(1) صرف‌نظر از تعداد Service.
• الگوریتم‌های LB متنوع پشتیبانی می‌شه: rr (round robin)، lc (least connection)، dh (destination hashing) و…
• برای فعال‌سازی باید ماژول‌های کرنل ip_vs, ip_vs_rr, ip_vs_wrr, ip_vs_sh, nf_conntrack روی نود لود شده باشن.
• در kube-proxy ConfigMap باید mode: ipvs ست بشه.

چک سریع مود فعلی:

1# دیدن مود فعال kube-proxy
2kubectl -n kube-system logs <kube-proxy-pod> | grep -i "Using ipvs\|Using iptables"
3
4# اگر ipvs هست:
5ipvsadm -Ln --stats
6
7# اگر iptables هست:
8iptables -t nat -L KUBE-SERVICES -n | head -20

نکته: وقتی از eBPF mode در Calico استفاده می‌کنی، هر دوی این‌ها کلاً کنار می‌رن و Calico خودش سرویس‌ها رو مدیریت می‌کنه (بخش ۶).

بخش ۴: مودهای Encapsulation در Calico — VXLAN, IPIP, No-Encap (BGP خالص)

Calico برای انتقال ترافیک Pod-to-Pod بین نودها، سه استراتژی اصلی داره. انتخاب این‌ها در IPPool (منبع IP Pod) تعریف می‌شه.

۴.۱ حالت بدون Encapsulation (Native Routing / Pure BGP)

1apiVersion: projectcalico.org/v3
2kind: IPPool
3spec:
4  cidr: 10.244.0.0/16
5  ipipMode: Never
6  vxlanMode: Never
7  natOutgoing: true

• پکت‌ها بدون هیچ لفاف اضافه‌ای (unencapsulated) مستقیماً روت می‌شن.
• نودها باید مستقیماً به هم Layer3 وصل باشن (یا از طریق روترهای فیزیکی که BGP رو یاد گرفتن، یا اگه همه روی یک L2 subnet هستن).
• بیشترین کارایی و کمترین Overhead (بدون افت MTU، بدون CPU اضافه برای Encap/Decap).
• بهترین انتخاب برای Bare-metal با روترهای BGP-capable یا کلاسترهایی که همه نودها روی یک subnet L2 هستن.
• ❌ روی اکثر Cloud Providerها (AWS, Azure, GCP پایه) کار نمی‌کنه چون شبکه ابری اجازه‌ی مسیریابی IPهای ناشناس (Pod CIDR) رو نمی‌ده مگر با تنظیمات خاص (مثل AWS VPC CNI-style route table یا GCP Alias IP).

۴.۲ IPIP Mode

1ipipMode: Always   # یا CrossSubnet یا Never

• پکت اورجینال IP-in-IP می‌شه (لفاف با پروتکل شماره 4 IP روی IP دیگه).
• سه حالت:
  • Always: همیشه Encapsulate کن (حتی داخل یک subnet)
  • CrossSubnet: فقط وقتی نودها روی subnetهای متفاوت هستن Encapsulate کن؛ اگه هم‌subnet بودن، Native Route بزن (بهترین ترکیب کارایی + سازگاری)
  • Never: خاموش
• Overhead کمتر از VXLAN داره (فقط ۲۰ بایت هدر اضافه، بدون هدر UDP).
• ⚠️ مشکل بزرگ: بعضی Cloud Providerها (به‌خصوص GCP و بعضی فایروال‌های Corporate) پروتکل IPIP رو بلاک می‌کنن چون UDP/TCP نیست و NAT/Security Groups راحت باهاش کار نمی‌کنن.
• روی AWS معمولاً کار می‌کنه (با فعال‌سازی Security Group مناسب).

۴.۳ VXLAN Mode

1vxlanMode: Always   # یا CrossSubnet یا Never

• پکت داخل یک بسته UDP روی پورت 4789 لفاف می‌شه (استاندارد VXLAN).
• Overhead بیشتر از IPIP: ۵۰ بایت (هدر Outer IP + UDP + VXLAN + Inner Ethernet).
• چون UDP هست، از همه فایروال‌ها و Cloud Providerها و NAT Gatewayها بدون مشکل رد می‌شه → سازگارترین گزینه.
• کمی کندتر از IPIP (به خاطر Overhead بیشتر و Encap/Decap سنگین‌تر در کرنل) مگراینکه از VXLAN Offload کارت شبکه پشتیبانی بشه.
• گزینه پیش‌فرض و امن برای اکثر نصب‌های Cloud/Managed Kubernetes وقتی BGP روتینگ ممکن نیست.

⚠️ نکته حیاتی MTU

با هر نوع Encapsulation، باید MTU رابط Pod رو کمتر از MTU فیزیکی تنظیم کنی، وگرنه پکت‌های بزرگ Fragment یا Drop می‌شن:

1# در Installation یا calico-config
2spec:
3  calicoNetwork:
4    mtu: 1450

اگر MTU اشتباه باشه، علامت کلاسیکش اینه: ping با پکت کوچیک کار می‌کنه ولی دانلود فایل بزرگ یا curl روی response بزرگ هنگ می‌کنه (چون Fragment یا PMTUD بلاک شده).

بخش ۵: BGP در Calico — عمیق‌تر

BGP روش Calico برای تبادل مسیرها (Route Advertisement) بین نودهاست، نه انتقال داده. حتی وقتی VXLAN/IPIP فعاله، BGP می‌تونه همچنان مسیرهای Service CIDR یا External رو تبلیغ کنه.

Node-to-Node Mesh (پیش‌فرض)

• هر نود با تمام نودهای دیگه یک BGP Peer مستقیم برقرار می‌کنه: O(n²) ارتباط.
• برای کلاسترهای کوچیک تا حدود ۵۰-۱۰۰ نود خوبه، بعدش سنگین می‌شه.

Route Reflector (RR) — برای مقیاس بزرگ

به جای Full Mesh، چند نود به عنوان Route Reflector انتخاب می‌شن و بقیه نودها فقط به RRها Peer می‌شن (نه به همدیگه):

1calicoctl patch node node-1 -p '{"spec":{"bgp":{"routeReflectorClusterID":"224.0.0.1"}}}'

1apiVersion: projectcalico.org/v3
2kind: BGPPeer
3metadata:
4  name: peer-to-rr
5spec:
6  peerSelector: route-reflector == 'true'

peering با روترهای فیزیکی (Top-of-Rack / ToR)

برای Native Routing واقعی در Bare-metal:

1apiVersion: projectcalico.org/v3
2kind: BGPPeer
3metadata:
4  name: rack1-tor
5spec:
6  peerIP: 192.168.10.1
7  asNumber: 65000

اینجا AS Number باید هماهنگ با روتر فیزیکی تنظیم بشه (calicoctl get bgpconfig -o yaml برای دیدن AS پیش‌فرض که معمولاً 64512 هست).

چک وضعیت BGP:

1calicoctl node status

خروجی نمونه سالم:

1IPv4 BGP status
2+--------------+-------------------+-------+----------+-------------+
3| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |    INFO     |
4+--------------+-------------------+-------+----------+-------------+
5| 172.16.0.11  | node-to-node mesh | up    | 10:23:11 | Established |
6| 172.16.0.12  | node-to-node mesh | up    | 10:23:15 | Established |
7+--------------+-------------------+-------+----------+-------------+

بخش ۶: Typha — چرا و کِی لازمه؟

بدون Typha، هر calico-node (یعنی هر Felix) مستقیماً به Kubernetes API Server وصل می‌شه و Watch باز می‌کنه. در کلاستر با ۵۰۰ نود = ۵۰۰ Watch مستقیم روی API Server → فشار سنگین.

Typha به عنوان یک لایه میانی عمل می‌کنه:

1API Server  <---چند Watch--->  Typha (چند replica)  <---هزاران اتصال--->  Felix روی هر نود

• توصیه رسمی Tigera: Typha رو از حدود ۵۰ نود به بالا فعال کن.
• تعداد Replica پیشنهادی: تقریباً یک Typha به ازای هر ۲۰۰ نود (حداقل ۳ replica برای HA).

1kubectl -n calico-system get deployment calico-typha
2kubectl -n calico-system logs -l k8s-app=calico-typha

اگه Typha از کار بیفته یا Felixها نتونن بهش وصل بشن، معمولاً می‌بینی که تغییرات Policy/IPPool با تأخیر زیاد یا اصلاً به نودها نمی‌رسه.

بخش ۷: eBPF Mode — نسل بعدی Data Plane

چرا eBPF؟

در مود کلاسیک (iptables/IPVS)، Felix سیاست‌ها رو در iptables می‌نویسه ولی سرویس‌ها (Service/ClusterIP) همچنان کار kube-proxy هست. در مود eBPF:

• Calico کاملاً جایگزین kube-proxy می‌شه — دیگه نیازی به kube-proxy نیست.
• به جای دنبال کردن Chainهای طولانی iptables، پکت با BPF Map Lookup به پیچیدگی O(1) مستقیم به Backend فرستاده می‌شه؛ صرف‌نظر از تعداد Serviceها سرعت ثابت می‌مونه.
• Source IP حفظ می‌شه حتی برای NodePort/LoadBalancer (که در مود کلاسیک با SNAT از بین می‌رفت مگر با externalTrafficPolicy: Local).
• پشتیبانی از DSR (Direct Server Return): ترافیک برگشتی مستقیم از نود Backend به کلاینت می‌ره، بدون برگشتن از نودی که اول پکت رو گرفته بود → کاهش لتنسی و حذف یک Hop اضافه.
• مصرف CPU به‌طور محسوس کمتر از iptables در کلاسترهای بزرگ.

پیش‌نیازها

• کرنل لینوکس 5.10 به بالا (یا توزیع‌هایی که Backport لازم رو دارن مثل RHEL 8.4+)
• توزیع پشتیبانی‌شده (Ubuntu 22.04+, RHEL/CentOS مناسب و…)

فعال‌سازی (روش دستی، کلاستر موجود)

 1# غیرفعال کردن kube-proxy (روش رایج: نودسلکتور غیرواقعی)
 2kubectl patch ds -n kube-system kube-proxy \
 3  -p '{"spec":{"template":{"spec":{"nodeSelector":{"non-calico":"true"}}}}}'
 4
 5# فعال‌سازی eBPF در FelixConfiguration
 6calicoctl patch felixconfiguration default --type merge \
 7  --patch '{"spec":{"bpfEnabled": true}}'
 8
 9# (اختیاری) فعال‌سازی DSR
10calicoctl patch felixconfiguration default --type merge \
11  --patch '{"spec":{"bpfExternalServiceMode":"DSR"}}'

< cite index=“15-1”>در روش‌های نصب مبتنی بر Operator روی kubeadm، این حالت به صورت پیش‌فرض فعال هست و برای فعال کردنش لازمه kube-proxy رو موقع نصب با فلگ مربوطه غیرفعال کنی.

تأیید فعال بودن eBPF

1# چک لاگ calico-node به دنبال BPF enabled
2kubectl -n calico-system logs <calico-node-pod> -c calico-node | grep -i bpf
3
4# ابزار داخلی برای بررسی مستقیم دیتاپلین eBPF
5kubectl exec -n calico-system <calico-node-pod> -c calico-node -- calico-node -bpf

< cite index=“13-1”>وضعیت دیتاپلین eBPF رو می‌تونی با بررسی لاگ‌های calico-node به دنبال عبارات BPF enabled یا starting BPF endpoint manager تأیید کنی، یا از دستور calico-node -bpf داخل پاد calico-node استفاده کنی.

نکات هشدار مهم eBPF

• < cite index=“14-1”>DSR نیاز به این داره که شبکه زیرین اجازه بده یک نود از طرف نود دیگه به کلاینت پاسخ بده؛ در شبکه‌های Cloud با محدودیت anti-spoofing ممکنه کار نکنه.
• < cite index=“13-1”>اگه به هر دلیلی مجبوری kube-proxy رو نگه داری، باید bpfKubeProxyIptablesCleanupEnabled رو false کنی و پورت health-check مربوط به kube-proxy در eBPF رو غیرفعال کنی تا با هم تداخل نکنن.
• < cite index=“14-1”>مهاجرت به eBPF نیازی به ری‌استارت نود نداره ولی چون نودها ممکنه در زمان‌های متفاوت به eBPF سوییچ کنن، باید rollout رو با دقت انجام بدی.

بخش ۸: جدول مقایسه کامل مودها

بخش ۹: سناریوهای Troubleshooting با راه‌حل کامل

مشکل ۱: Podها روی نودهای مختلف نمی‌تونن به هم Ping بزنن

علائم: ping بین دو Pod روی دو نود مختلف Timeout می‌ده، ولی روی یک نود کار می‌کنه.

چک‌لیست:

 1# ۱- وضعیت کلی BGP رو ببین
 2calicoctl node status
 3
 4# ۲- مسیر (route) به Pod CIDR نود مقصد رو روی نود مبدا چک کن
 5ip route show | grep <remote-pod-cidr>
 6
 7# ۳- اگه IPIP/VXLAN فعاله، اینترفیس مربوطه رو چک کن
 8ip link show tunl0    # برای IPIP
 9ip link show vxlan.calico   # برای VXLAN
10
11# ۴- وضعیت calico-node رو روی هر دو نود ببین
12kubectl -n calico-system get pods -o wide | grep calico-node
13kubectl -n calico-system logs <calico-node-pod> -c calico-node | tail -50

علل رایج و راه‌حل:

• Security Group/Firewall بین نودها پروتکل IPIP (پروتکل ۴) یا پورت UDP 4789 (VXLAN) یا BGP (TCP 179) رو بلاک کرده. → قوانین فایروال رو باز کن.
• ipipMode/vxlanMode اشتباه تنظیم شده (مثلاً CrossSubnet ولی نودها روی subnetهای متفاوتن و فایروال بین‌subnetی IPIP رو بلاک کرده). → با calicoctl get ippool -o yaml بررسی و اصلاح کن.
• BGP Peer در حالت down یا start به جای up. → لاگ BIRD رو ببین:

1kubectl -n calico-system exec <calico-node-pod> -c calico-node -- birdcl -s /var/run/calico/bird.ctl show protocols

مشکل ۲: NetworkPolicy اعمال نمی‌شه (ترافیکی که باید بلاک بشه رد می‌شه یا برعکس)

 1# ۱- ببین Policy واقعاً ساخته شده
 2kubectl get networkpolicy -A
 3calicoctl get networkpolicy -A -o yaml
 4
 5# ۲- چک کن Felix پالیسی رو خونده (در لاگ)
 6kubectl -n calico-system logs <calico-node-pod> -c calico-node | grep -i "policy"
 7
 8# ۳- در مود iptables، chain مربوط به policy رو مستقیم چک کن
 9iptables -L cali-fw-<interface-id> -n -v
10
11# ۴- در مود eBPF از ابزار BPF policy dump استفاده کن
12kubectl exec -n calico-system <calico-node-pod> -c calico-node -- calico-node -bpf policy dump <interface>

علل رایج:

• ترتیب Policy اشتباه — اگه چند NetworkPolicy با order مختلف داری، ترتیب پایین‌تر (عدد کوچیک‌تر) اول اجرا می‌شه؛ یه Policy Deny با order پایین می‌تونه یه Allow با order بالاتر رو override کنه.
• Label Selector اشتباه روی Pod یا Namespace — با kubectl get pod --show-labels مطمئن شو Selector واقعاً match می‌کنه.
• فراموش کردن Egress DNS: اگه Policy رو محدود به Ingress/Egress خاص کردی ولی اجازه‌ی DNS (پورت 53 به CoreDNS) رو ندادی، Pod نمی‌تونه Resolve کنه و انگار «همه‌چی خرابه» به نظر می‌رسه در حالی که فقط DNS بلاکه. راه‌حل: همیشه یک Policy پایه برای اجازه‌ی Egress به kube-dns بساز.
• Default Deny رو ست کردی ولی Podهای سیستمی (kube-system) رو استثنا نکردی → مشکلات زنجیره‌ای در کل کلاستر.

مشکل ۳: کندی یا Timeout روی انتقال فایل‌های بزرگ (نه Ping ساده)

علامت کلاسیک MTU: ping -s 1400 جواب می‌ده ولی curl یک فایل بزرگ یا scp گیر می‌کنه یا خیلی کند می‌شه.

1# تست دقیق با DF (Don't Fragment) برای پیدا کردن حداکثر MTU واقعی مسیر
2ping -M do -s 1472 <remote-pod-ip>   # 1472 + 28(header) = 1500
3# اگه جواب نداد، کم کن تا جواب بده -> این عدد MTU واقعی مسیرته
4
5# چک MTU فعلی اینترفیس Pod
6kubectl exec <pod> -- ip link show eth0
7
8# چک MTU تنظیم‌شده در Calico
9kubectl -n calico-system get installation default -o yaml | grep -i mtu

راه‌حل: MTU پیشنهادی رو مطابق جدول بخش ۴ در Installation (یا calico-config ConfigMap در نصب‌های manifest-based) تنظیم کن و منتظر بمون تا calico-node روی همه نودها رفرش بشه (یا rolling restart بزن).

مشکل ۴: خطای IPAM — “no IP addresses available” یا Pod در حالت ContainerCreating گیر می‌کنه

 1kubectl describe pod <pod-name> | grep -A5 Events
 2# معمولاً می‌بینی: "Failed to allocate IP for ... no IPs available in pool"
 3
 4# چک تعداد IP آزاد در هر IPPool
 5calicoctl ipam show
 6
 7# چک IP بلاک‌های اختصاص داده شده به هر نود
 8calicoctl ipam show --show-blocks
 9
10# اگه IPهای Leak شده (Pod حذف شده ولی IP آزاد نشده) داری:
11calicoctl ipam check
12calicoctl ipam release --ip=<leaked-ip>

علل رایج:

• CIDR کلاستر خیلی کوچیکه یا blockSize (پیش‌فرض /26 روی هر نود) باعث شده در نودهای پرتراکم زود تموم بشه.
• IPAM Garbage Collector (بخشی از kube-controllers) کار نمی‌کنه:

1kubectl -n calico-system logs -l k8s-app=calico-kube-controllers

مشکل ۵: Typha در دسترس نیست / Felix نمی‌تونه Connect کنه

1kubectl -n calico-system get pods -l k8s-app=calico-typha
2kubectl -n calico-system logs <typha-pod>
3
4# روی هر نود، بررسی کن Felix به کدوم Typha وصله
5kubectl -n calico-system logs <calico-node-pod> -c calico-node | grep -i typha

علائم: تغییرات IPPool/Policy با تأخیر زیاد به نودها می‌رسه، یا در کلاستر بزرگ فشار زیاد روی API Server می‌بینی (kubectl top pod -n kube-system روی kube-apiserver).

راه‌حل:

• تعداد Replica Typha رو با اندازه کلاستر متناسب کن.
• مطمئن شو Service calico-typha به درستی به Podهای Typha می‌رسه (kubectl get endpoints calico-typha -n calico-system).
• در نصب‌های خیلی بزرگ، فعال بودن TyphaCA/TLS رو چک کن (خطاهای گواهی معمولاً در لاگ Felix با x509 مشخصن).

مشکل ۶: BGP Peer در حالت Active یا Connect گیر کرده (Established نمی‌شه)

1calicoctl node status
2# اگه STATE چیزی جز "up" باشه، مشکل داری
3
4kubectl -n calico-system exec <calico-node-pod> -c calico-node -- \
5  birdcl -s /var/run/calico/bird.ctl show protocols all Mesh_172_16_0_11

علل رایج:

• پورت TCP 179 (BGP) توسط فایروال بین نودها بلاک شده.
• AS Number ناهماهنگ بین دو طرف Peer (مخصوصاً وقتی به روتر فیزیکی Peer می‌شی).
• node-to-node mesh فعاله ولی همزمان BGPPeer دستی هم تعریف کردی که باعث Conflict می‌شه.

1calicoctl get bgpconfig default -o yaml   # چک کن nodeToNodeMeshEnabled چیه

مشکل ۷: در مود eBPF، سرویس‌ها (ClusterIP/NodePort) کار نمی‌کنن

1# چک کن واقعاً bpfEnabled فعاله
2calicoctl get felixconfiguration default -o yaml | grep bpf
3
4# چک کن kube-proxy واقعاً حذف/غیرفعال شده (نباید همزمان با eBPF فعال باشه)
5kubectl -n kube-system get ds kube-proxy
6
7# دیدن Serviceهایی که eBPF می‌بینه
8kubectl exec -n calico-system <calico-node-pod> -c calico-node -- calico-node -bpf svc dump

علل رایج:

• kube-proxy هنوز فعاله و با eBPF تداخل داره — دو مسیر مختلف برای همون Service باعث رفتار نامشخص می‌شه. راه‌حل: کامل غیرفعالش کن یا طبق راهنمای بخش ۷ تنظیمات cleanup رو انجام بده.
• DSR فعاله ولی شبکه زیرین اجازه Direct Return نمی‌ده (خصوصاً روی Cloud با Anti-spoofing/Source-Dest check فعال). راه‌حل: یا DSR رو خاموش کن (bpfExternalServiceMode: Tunnel) یا روی Cloud مربوطه Source/Destination check رو برای اینترفیس نود غیرفعال کن (مثلاً AWS: Change Source/Dest. Check).
• کرنل نود قدیمی‌تر از 5.10 هست → eBPF Silent Fail می‌کنه یا اصلاً لود نمی‌شه؛ حتماً از لاگ‌ها مطمئن شو.

مشکل ۸: تشخیص این‌که مشکل از Calico هست یا از خود اپلیکیشن/DNS

یک روش سیستماتیک لایه‌به‌لایه:

 1# لایه ۱: خود Pod IP بدون DNS - مستقیم Ping بزن
 2kubectl exec -it <pod-a> -- ping -c3 <pod-b-ip>
 3
 4# لایه ۲: Service ClusterIP (بدون DNS Name)
 5kubectl exec -it <pod-a> -- curl -v <service-clusterip>:<port>
 6
 7# لایه ۳: Service با DNS Name (تست خود CoreDNS)
 8kubectl exec -it <pod-a> -- nslookup <service-name>.<namespace>.svc.cluster.local
 9
10# لایه ۴: NetworkPolicy رو موقتاً از معادله حذف کن (فقط برای تست!)
11kubectl get networkpolicy -A -o name | xargs -I{} kubectl delete {}
12# تست کن، اگه درست شد یعنی مشکل از Policy بوده - Policyها رو با دقت برگردون

این روش دقیقاً مشخص می‌کنه مشکل کجاست: اگه لایه ۱ خرابه = مشکل Calico Data Plane (روتینگ/Encap)؛ اگه لایه ۲ خرابه ولی ۱ خوبه = مشکل kube-proxy/eBPF Service routing؛ اگه فقط لایه ۳ خرابه = مشکل CoreDNS؛ اگه فقط با Policy فعال خرابه = مشکل NetworkPolicy.

بخش ۱۰: ابزارهای ضروری Debug (خلاصه مرجع)