Kubernetes نیٹ ورکنگ کی وضاحت کی گئی: ClusterIP سے Cilium Service Mesh تک

از /

یہ وہ ہے جو زیادہ تر Kubernetes ٹیوٹوریلز آپ کو نہیں بتاتے ہیں: زیادہ تر انجینئر اس قابل ہوں گے: kubectl expose. 10% سے کم لوگ سمجھتے ہیں کہ جب وہ ایسا کرتے ہیں تو کیا ہوتا ہے۔

میں نے 10 سے زیادہ کمپنیوں میں Kubernetes نیٹ ورکنگ کے مسائل کو ڈیبگ کیا ہے۔ علم کا ایک ہی خلا ہر بار ظاہر ہوتا ہے۔ انجینئرز یہ نہیں سمجھتے کہ کلسٹر آئی پی اندرونی طور پر کیسے کام کرتا ہے۔ وہ نہیں سمجھتے کہ مختلف نام کی جگہوں میں پوڈز ایک دوسرے سے مقامی طور پر کیوں بات کر سکتے ہیں۔ اور وہ نہیں سمجھتے کہ CNI پلگ ان اصل میں کرنل کی سطح پر کیا کرتا ہے۔

یہ ٹیوٹوریل حل ہے۔ آپ یہ سیکھیں گے کہ Kubernetes نیٹ ورکنگ نیچے سے کیسے کام کرتی ہے، بشمول پوڈ آئی پی کو کس طرح تفویض کیا جاتا ہے اور وہ نوڈس پر کیوں کام کرتے ہیں، کیوب پراکسی iptables کے قوانین کا استعمال کرتے ہوئے کلسٹر آئی پی کو کس طرح لاگو کرتی ہے، کس طرح Ingress کنٹرولر بیرونی ٹریفک کو سنگل لوڈ بیلنس کے ذریعے روٹ کرتا ہے، نیٹ ورک کی پالیسیاں کس طرح SOC2 کی تعمیل کے لیے مائیکرو سیگمینٹیشن کو نافذ کرتی ہیں، EB کو تیزی سے تبدیل کرنے کے لیے اور تمام EB کو تبدیل کرنے کے لیے قابل مشاہدہ، اور زیادہ محفوظ متبادل۔

اس گائیڈ کے اختتام تک، آپ "میرے پوڈز اس سروس کے ساتھ بات چیت کیوں نہیں کر سکتے؟” کو ڈیبگ کرنے کے قابل ہو جائیں گے، پہلے سے طے شدہ انکار نیٹ ورک کی پالیسی کو لاگو کریں جو SOC2 CC6.1 پر پورا اترتی ہو، اور اعتماد کے ساتھ اپنے کلسٹر کے لیے صحیح CNI کا انتخاب کریں۔

انڈیکس

جو آپ سیکھیں گے۔

  • Pod IP، کنٹینر نیٹ ورک ماڈل، کس طرح CNI پتے مختص کرتا ہے۔

  • kube-proxy iptables کے ساتھ ClusterIP کو کیسے نافذ کرتا ہے اور eBPF تیز کیوں ہے

  • انگریس کنٹرولر: تمام بیرونی ٹریفک کو ایک ہی لوڈ بیلنسر کے ذریعے روٹ کرتا ہے۔

  • نیٹ ورک کی پالیسی: ڈیفالٹ انکار اور فی سروس صفر ٹرسٹ نیٹ ورکنگ کے اصولوں کی اجازت دیتا ہے۔

  • CNI موازنہ: Cilium, Calico, AWS VPC CNI اور ہر ایک کو کب استعمال کرنا ہے۔

  • سروس میش: Cilium, Istio, Linkerd for mTLS اور مشاہدہ کے لیے

آئیے اندر غوطہ لگاتے ہیں۔

شرطیں

پیروی کرنے سے پہلے، آپ کو ضرورت ہو گی:

علم:

  • بنیادی Kubernetes واقفیت: آپ پوڈ تعینات کر سکتے ہیں اور خدمات تخلیق کر سکتے ہیں۔

  • بنیادی لینکس نیٹ ورکنگ تصورات: آپ جانتے ہیں کہ IP ایڈریس اور پورٹ کیا ہیں۔

  • لوڈ بیلنسر کی صلاحیتوں کی عمومی تفہیم

اوزار اور رسائی:

  • Kubernetes کلسٹر چلانا (EKS، GKE، یا کسی دوسری قسم کے ذریعے مقامی کلسٹر)

  • kubectl ترتیب دینا اور ایک کلسٹر کی طرف اشارہ کرنا

  • helm 3 تنصیبات (حصہ 4 میں سیلیم کی تنصیب کے لیے)

  • حصہ 4 اور اس کے بعد: اپنے کلسٹر پر Cilium انسٹال کرنا (helm install cilium cilium/cilium)

CNI کے بارے میں نوٹ: حصے 1-3 کا اطلاق CNI سے قطع نظر تمام Kubernetes کلسٹرز پر ہوتا ہے۔ حصوں 4 سے 6 میں سیلیم سے متعلقہ وسائل شامل ہیں (CiliumNetworkPolicyہبل)۔ اگر آپ ایک مختلف CNI استعمال کرتے ہیں، تو تصور ایک جیسا ہے۔ صرف YAML نحو مختلف ہے۔

حصہ 1: Pod IP اور کنٹینر نیٹ ورک ماڈل

1.1 ہر پوڈ کا اپنا IP کیوں ہوتا ہے۔

Kubernetes نیٹ ورکنگ ماڈل کا ایک بنیادی اصول ہے: ہر Pod کا ایک منفرد IP پتہ ہوتا ہے، اور ہر Pod اس IP کو نیٹ ورک ایڈریس ٹرانسلیشن (NAT) کے بغیر ہر دوسرے Pod کے ساتھ بات چیت کرنے کے لیے استعمال کر سکتا ہے۔

یہ ڈوکر کے ڈیفالٹ رویے سے مختلف ہے، جہاں کنٹینرز میزبان نیٹ ورک کا اشتراک کرتے ہیں یا پورٹ میپنگ کا استعمال کرتے ہیں۔ Kubernetes میں pods کے درمیان پورٹ میپنگ نہیں ہے۔ آئی پی کا پوڈ اے 10.244.1.2 Pod B تک براہ راست پہنچا جا سکتا ہے۔ 10.244.2.3 یہ مختلف نوڈس پر پھیلا ہوا ہے اور سورس آئی پی محفوظ ہے۔

اپنے کلسٹر کے لیے اسے چیک کریں۔

# List all pods across all namespaces with their IP addresses and node placement
kubectl get pods -o wide --all-namespaces

متوقع پیداوار:

NAMESPACE     NAME                                READY   STATUS    IP            NODE
production    payment-api-5d6b8d8c4f-abc12        1/1     Running   10.244.1.2    node-1
production    user-api-5d6b8d8c4f-def34           1/1     Running   10.244.2.3    node-2
production    redis-master-0                      1/1     Running   10.244.1.4    node-1

ہر پوڈ کا ایک منفرد IP ہوتا ہے۔ نوڈ-1 پر ادائیگی-اے پی آئی اور نوڈ-2 پر صارف-اے پی آئی متعلقہ IP پر براہ راست ایک دوسرے سے جڑ سکتے ہیں۔ IP اس سے آتا ہے: 10.244.0.0/16 CIDR: ایک پوڈ نیٹ ورک جو نوڈ نیٹ ورک سے الگ ہے۔

1.2 CNI پلگ ان اصل میں کیا کرتا ہے۔

کنٹینر نیٹ ورک انٹرفیس (CNI) ایک پلگ ان ہے جو Kubernetes نیٹ ورکنگ ماڈل کو چلانے کے لیے ذمہ دار ہے۔ جب نوڈ پر ایک نیا پوڈ مقرر کیا جاتا ہے، تو Kubernetes kubelet CNI پلگ ان کو کال کرتا ہے، جو چار کام انجام دیتا ہے:

  1. اپنے Pod کے لیے ایک نیا نیٹ ورک نام کی جگہ بنائیں، جو کہ ایک الگ تھلگ نیٹ ورکنگ ماحول ہے۔

  2. ایک ورچوئل ایتھرنیٹ جوڑا بنائیں (veth): پوڈ نام کی جگہ کے اندر ایک سرہ، نوڈ پر ایک سرا

  3. پوڈ کی ویتھ جوڑی کے آخر میں کلسٹر پوڈ CIDR کا IP ایڈریس تفویض کریں۔

  4. روٹنگ کے اصول شامل کریں تاکہ نوڈس کو معلوم ہو کہ کلسٹر میں موجود تمام پوڈ آئی پی سے کیسے جڑنا ہے۔

سی این آئی کے بغیر، پوڈ نیٹ ورک سے نہیں جڑے گا۔ یہ فلیٹ پوڈ نیٹ ورک ماڈل کو حقیقت بناتا ہے۔

چیک کریں کہ آپ کے کلسٹر پر کون سے CNI پلگ ان انسٹال ہیں۔

# List the CNI binaries installed on a node
ls /opt/cni/bin/

ذیل میں کچھ عام CNI پلگ ان اور ہر ایک کو کب استعمال کرنا ہے۔

سی این آئی کیا یہ بطور ڈیفالٹ آن ہے؟ کلیدی استعمال کے معاملات
AWS VPC CNI ہاں (EKS) پھلیوں کو ایک حقیقی VPC IP ملتا ہے۔ AWS مقامی انضمام کے لیے بہترین موزوں ہے۔
کیلیکو نہیں BGP روٹنگ کا استعمال کرتے ہوئے جدید نیٹ ورک پالیسی
پلکیں نہیں eBPF پر مبنی نیٹ ورکنگ، پرت 7 پالیسی، سروس میش، SOC2 ثبوت

1.3 پھلیوں کے درمیان رابطے کی جانچ کریں۔

نیٹ ورکنگ کا سب سے بنیادی ٹیسٹ: ایک پوڈ کے ساتھ چلائیں اور دوسرے پوڈ کو آئی پی کے ذریعے پنگ کریں۔

# Step 1: Get the IP of a target pod
TARGET_IP=$(kubectl get pod redis-master-0 -o jsonpath="{.status.podIP}")
echo "Target IP: $TARGET_IP"

# Step 2: Exec into another pod and ping the target
kubectl exec -it payment-api-5d6b8d8c4f-abc12 -- ping -c 3 $TARGET_IP

متوقع پیداوار:

PING 10.244.1.4 (10.244.1.4): 56 data bytes
64 bytes from 10.244.1.4: icmp_seq=0 ttl=62 time=0.8ms
64 bytes from 10.244.1.4: icmp_seq=1 ttl=62 time=0.7ms
64 bytes from 10.244.1.4: icmp_seq=2 ttl=62 time=0.9ms

اگر یہ کامیاب ہو جاتا ہے، تو آپ کا CNI صحیح طریقے سے کام کر رہا ہے۔ اگر یہ ناکام ہوجاتا ہے، تو چیک کریں کہ آیا آپ کے نیٹ ورک کی پالیسی ICMP ٹریفک کو روک رہی ہے (اس کا احاطہ حصہ 4 میں کیا گیا ہے)۔

یاد رکھنے کا ایک اصول یہ ہے کہ ہر پوڈ کو ایک IP دیا جاتا ہے۔ پوڈس اپنے آئی پی کا استعمال کرتے ہوئے براہ راست بات چیت کرسکتے ہیں۔ CNI پلگ ان دونوں کو حاصل کرتا ہے۔

حصہ 2: خدمات — کلسٹر آئی پی، نوڈ پورٹ، اور لوڈ بیلنس

2.1 مسئلہ: Pod IP مستحکم نہیں ہے۔

Pod IP ہر بار جب Pod دوبارہ شروع ہوتا ہے تبدیل ہوتا ہے۔ جب آپ اپنے Payments API کا نیا ورژن تعینات کرتے ہیں، تو پرانا Pod حذف ہو جاتا ہے اور نئے IP کا استعمال کرتے ہوئے ایک نیا Pod بنایا جاتا ہے۔ پرانے آئی پی کو کال کرنے کے لیے کنفیگر کردہ کسی بھی خدمات کا اب ڈیڈ حوالہ ہوگا۔

غلط نقطہ نظر ہے: اس میں Pod IP کو ہارڈ کوڈنگ کرنا شامل ہے۔

# Bad: Direct Pod IP in application configuration
# This IP will stop working the next time the database Pod restarts
apiVersion: v1
kind: Pod
metadata:
  name: payment-api
spec:
  containers:
  - name: api
    env:
    - name: DATABASE_HOST
      value: "10.244.1.4"  # Pod IP — will change on next restart

یہ ترقی کو کمزور اور پیداوار کو تباہ کن بنا دیتا ہے۔ روٹین پوڈ کو دوبارہ شروع کرنا، جیسے کہ نوڈ ڈریننگ، OOM شٹ ڈاؤن، یا تعیناتی رول آؤٹ، کسی بھی ایسی ایپلی کیشن کو توڑ دے گا جس نے پرانے IP کو ہارڈ کوڈ کیا ہو۔

2.2 سروس استحکام کے مسائل کو کیسے حل کرتی ہے۔

Kubernetes سروسز دو خصوصیات فراہم کرتی ہیں جو Pod IPs نہیں کر سکتے ہیں: ایک مستحکم IP ایڈریس جو سروس کی زندگی کے دوران کبھی تبدیل نہیں ہوتا ہے (ClusterIP)، اور ایک مستحکم DNS نام جو دوسرے Pods کے ذریعے استعمال کیا جا سکتا ہے ان کے IP سے قطع نظر۔

جب آپ کوئی سروس بناتے ہیں، تو Kubernetes سروس CIDR سے ایک ورچوئل کلسٹر آئی پی تفویض کرتا ہے، جیسے 10.100.0.0/16)، CoreDNS میں درج ذیل ایک DNS ریکارڈ بنائیں: ..svc.cluster.localکلسٹر آئی پی سے اس کے پیچھے صحت مند پوڈ آئی پی پر بیلنس ٹریفک لوڈ کرنے کے لیے iptables اصول شامل کرنے کے لیے تمام نوڈس پر kube-proxy کو ترتیب دیں۔

درست نفاذ کلسٹر آئی پی سروس ہے۔

# Good: ClusterIP Service provides a stable IP and DNS name
# redis.production.svc.cluster.local always resolves to 10.100.0.1
# regardless of which Redis pods are running behind it
apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: production
spec:
  selector:
    app: redis
    role: master   # Only pods with these labels receive traffic
  ports:
  - port: 6379        # Port the Service listens on
    targetPort: 6379  # Port the Pod actually runs on
  type: ClusterIP     # Default: accessible only inside the cluster

iptables کا استعمال کرتے ہوئے kube-proxy کس طرح لوڈ بیلنسنگ کو لاگو کرتا ہے: جب کوئی سروس بنائی جاتی ہے، تو kube-proxy کلسٹر میں موجود تمام نوڈس میں iptables کے اصول شامل کر دیتی ہے۔ یہ قواعد ClusterIP کے لیے طے شدہ ٹریفک کو روکتے ہیں اور اسے صحت مند Pod IPs میں سے ایک پر بھیج دیتے ہیں۔ قوانین کو عمل میں دیکھنے کے لیے اسے اپنے نوڈ پر چلائیں۔

# View the iptables rules kube-proxy created for the redis Service
# Each KUBE-SEP entry represents one Pod endpoint
sudo iptables -t nat -L KUBE-SERVICES | grep redis

متوقع پیداوار:

Chain KUBE-SVC-REDIS (1 references)
target          prot  source    destination
KUBE-SEP-AAA    all   anywhere  anywhere    /* production/redis */ statistic mode random probability 0.50
KUBE-SEP-BBB    all   anywhere  anywhere    /* production/redis */

Redis ClusterIP کی طرف ٹریفک ان iptables قواعد کے ذریعے دو پوڈ اینڈ پوائنٹس کے درمیان 50/50 تقسیم کی جاتی ہے۔ جب پوڈ دوبارہ شروع ہوتا ہے اور ایک نیا IP موصول ہوتا ہے، تو kube-proxy خود بخود قوانین کو اپ ڈیٹ کر دیتا ہے۔

2.3 ہر قسم کی سروس کا استعمال کب کرنا ہے۔

زمرہ DNS نام سے قابل رسائی: کیسز استعمال کریں۔
کلسٹر آئی پی redis.production.svc.cluster.local صرف کلسٹر کے اندر ڈیٹا بیس، کیشے، اندرونی API
نوڈ پورٹ :30000–32767 نوڈ آئی پی + پورٹ مقامی ترقی، ڈیبگنگ
لوڈ بیلنسر AWS ELB DNS نام انٹرنیٹ (کلاؤڈ لوڈ بیلنسر کے ذریعے) بیرونی API، ویب ایپلیکیشن

تصدیق کریں کہ سروس ٹریفک کو صحیح طریقے سے روٹ کر رہی ہے۔

# Describe a Service to see its endpoints (the actual Pod IPs behind it)
kubectl describe service redis -n production

متوقع پیداوار:

Name:              redis
Namespace:         production
Type:              ClusterIP
IP:                10.100.0.1
Port:              6379/TCP
TargetPort:        6379/TCP
Endpoints:         10.244.1.4:6379,10.244.2.5:6379
Session Affinity:  None

اگر Endpoints دکھائیں سروس سلیکٹر چلنے والے پوڈ سے مماثل نہیں ہے۔ یہ Kubernetes میں "کنکشن سے انکار” کی غلطیوں کی سب سے عام وجہ ہے۔

یاد رکھنے کا ایک اصول یہ ہے کہ پوڈز کو ہمیشہ سروس DNS نام سے جڑنا چاہیے، پوڈ IP سے نہیں۔ سروس خود بخود قابل اعتماد، لوڈ بیلنسنگ، اور صحت کی جانچ کو سنبھالتی ہے۔

حصہ 3: داخل – بیرونی ٹریفک روٹنگ

3.1 مسئلہ: لوڈ بیلنسر سروس فی مائیکرو سروس مہنگی ہے۔

ہر ایک LoadBalancer سروس ایک وقف شدہ کلاؤڈ لوڈ بیلنس تخلیق کرتی ہے۔ AWS میں، ہر ایپلیکیشن لوڈ بیلنس کی قیمت تقریباً $(0.008/LCU-hour + $)0.0225/hour بنیادی شرح ہے۔ اس کی لاگت تقریباً $16-27 فی مہینہ فی لوڈ بیلنسر ہے۔

20 مائیکرو سروسز کے لیے، اکیلے لوڈ بیلنس کی فیس $320 سے $540 فی مہینہ تک، اس کے علاوہ ہر درخواست پر کارروائی کے لیے $0.008/LCU۔

یہاں ایک خراب نقطہ نظر ہے: فی مائیکرو سروس ایک لوڈ بیلنسر کا استعمال۔

# Bad: This creates a new AWS ALB every time it is applied
# 20 microservices = 20 ALBs = $300-500/month before any traffic charges
apiVersion: v1
kind: Service
metadata:
  name: payment-api
spec:
  type: LoadBalancer   # Creates a dedicated ALB
  ports:
  - port: 80
    targetPort: 8080

3.2 وصول کرنے والا کنٹرولر اس مسئلے کو کیسے حل کرتا ہے۔

Ingress کنٹرولر ایک پوڈ ہے جو کلسٹر کے اندر چلتا ہے اور دیکھتا ہے: Ingress میزبان نام اور یو آر ایل پاتھ کی بنیاد پر متعدد سروسز تک ٹریفک کو روٹ کرنے کے لیے ایک واحد بیرونی لوڈ بیلنس کو وسائل اور پروگرام کریں۔

مثال کے طور پر، AWS لوڈ بیلنس کنٹرولر تمام Ingress وسائل کے لیے ایک ALB بناتا ہے اور ان کو روٹ کرنے کے لیے پروگرام سننے والے کے اصول۔ api.company.com/payments ادائیگی کی خدمت کے لیے api.company.com/users سبھی کو ایک ہی لوڈ بیلنسر کے ذریعے آپ کی خدمات تک پہنچایا جاتا ہے۔

درست نفاذ یہ ہے: تمام خدمات کے لیے ایک داخل۔

# Good: One Ingress resource routes all external traffic
# One ALB is created total, regardless of how many services are listed
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shared-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
spec:
  rules:
  - host: api.company.com
    http:
      paths:
      - path: /payments
        pathType: Prefix
        backend:
          service:
            name: payment-service
            port:
              number: 8080
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 8080
  - host: dashboard.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: dashboard-service
            port:
              number: 3000
  tls:
  - hosts:
    - api.company.com
    - dashboard.company.com
    secretName: tls-wildcard-cert

یقینی بنائیں کہ داخلے کا انتظام کیا گیا ہے اور ایک ALB DNS نام تفویض کیا گیا ہے۔

# Watch until the ADDRESS column shows the ALB DNS name (typically 2-3 minutes)
kubectl get ingress shared-ingress -n production -w

متوقع پیداوار:

NAME             CLASS   HOSTS                                    ADDRESS                                              PORTS
shared-ingress   alb     api.company.com,dashboard.company.com   k8s-prod-sharedin-abc123.us-east-1.elb.amazonaws.com   80, 443

لاگت کا فرق:

نقطہ نظر لوڈ بیلنسر ماہانہ لاگت
لوڈ بیلنس سروس فی مائیکرو سروس (20 سروسز) 20 ALBs ~$400/مہینہ
واحد وصول کرنے والا کنٹرولر 1 البی ~$27/مہینہ

یاد رکھنے کا ایک اصول یہ ہے کہ روٹ پر مبنی روٹنگ والا ایک Ingress کنٹرولر ایک ہی لوڈ بیلنسر کے ذریعے تمام خدمات فراہم کرتا ہے۔ فی سروس LoadBlancer اپروچ صرف ابتدائی پروٹو ٹائپس کے لیے استعمال ہوتا ہے۔

حصہ 4: نیٹ ورک پالیسی – مائیکرو سیگمنٹیشن

4.1 ڈیفالٹ: تمام پوڈز دیگر تمام پوڈز سے بات کر سکتے ہیں۔

پہلے سے طے شدہ طور پر، Kubernetes pods کے درمیان نیٹ ورک کی پابندیاں نافذ نہیں کرتا ہے۔ فرنٹ اینڈ پوڈز براہ راست ڈیٹا بیس پوڈز پر API کال کر سکتے ہیں۔ تجزیاتی سروس بلنگ ڈیٹا بیس سے استفسار کر سکتی ہے۔ سمجھوتہ شدہ پوڈ کلسٹر میں موجود دیگر تمام پوڈز کو اسکین کر سکتا ہے۔

یہ محفوظ نہیں ہے۔ SOC2 CC6.1 (Logical Access Control)، HIPAA، اور زیادہ تر انٹرپرائز سیکیورٹی فریم ورک کے لیے، آپ کو یہ ثابت کرنے کے قابل ہونا چاہیے کہ نیٹ ورک ٹریفک ضروری حد تک محدود ہے۔

چیک کریں کہ آیا آپ کے پاس فی الحال لامحدود ٹریفک ہے۔

# Without Network Policies, this call from the frontend to the payment DB will succeed
# It should not be allowed in a secure cluster
kubectl exec -it frontend-pod -n production -- \
  curl http://payment-postgres.production.svc.cluster.local:5432

اگر یہ آپ کے کلسٹر میں کامیاب ہو جاتا ہے، تو کوئی نیٹ ورک پارٹیشن نہیں ہے۔

4.2 حل: Cilium نیٹ ورک پالیسی کے ذریعے ڈیفالٹ انکار

صحیح نقطہ نظر پہلے سے طے شدہ انکار ہے۔ سب سے پہلے، پوڈز کے درمیان تمام ٹریفک کو مسدود کریں، اور پھر واضح طور پر صرف ان مخصوص مواصلاتی راستوں کی اجازت دیں جو آپ کی درخواست کے لیے درکار ہیں۔

مرحلہ 1 – پہلے سے طے شدہ انکار کی پالیسی کا اطلاق کریں۔

# This policy applies to all pods in the namespace (empty endpointSelector matches all)
# It blocks all ingress and egress traffic by default
# Warning: apply this and all pod-to-pod communication immediately stops
# Have your allow rules ready before applying this in production
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  description: "Block all inter-pod traffic by default — zero-trust baseline"
  endpointSelector: {}  # Matches all pods in this namespace
  ingress:
  - {}                  # Empty ingress rule = deny all inbound
  egress:
  - {}                  # Empty egress rule = deny all outbound

پہلے سے طے شدہ انکار پالیسی کو لاگو کرنے سے نام کی جگہ میں موجود تمام پوڈز کے درمیان رابطے فوری طور پر بند ہو جاتے ہیں۔ قبولیت کے وہی اصول لاگو کریں (نیچے)۔ kubectl apply ایک کمانڈ جاری کریں یا پہلے اجازت نامے کا اطلاق کریں۔

مرحلہ 2 – نام کی جگہ کی سطح کی تنہائی شامل کریں۔

# Allow pods to communicate within the same namespace
# Block cross-namespace traffic by default
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  endpointSelector: {}
  ingress:
  - fromEndpoints:
    - matchLabels:
        io.kubernetes.pod.namespace: production
  egress:
  - toEndpoints:
    - matchLabels:
        io.kubernetes.pod.namespace: production

مرحلہ 3 – سروس کے لیے مخصوص اجازت کے اصول شامل کریں۔

# Grant the payment service only the specific network access it needs
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payment-service-network-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  egress:
  # Allow: payment-service → postgres on port 5432
  - toEndpoints:
    - matchLabels:
        app: postgres-db
    toPorts:
    - ports:
      - port: "5432"
        protocol: TCP
  # Allow: payment-service → Stripe API externally
  - toFQDNs:
    - matchName: "api.stripe.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

4.3 پالیسیوں کی تصدیق اور SOC2 ثبوت جمع کرنے کے لیے ہبل کا استعمال

Cilium میں Hubble شامل ہے، ایک نیٹ ورک مشاہداتی ٹول جو آپ کو بالکل ظاہر کرتا ہے کہ آپ کے نیٹ ورک کی پالیسیوں کی بنیاد پر کن بہاؤ کی اجازت ہے اور کن کو مسترد کر دیا گیا ہے۔ ہبل SOC2 ثبوت ہے کہ نیٹ ورک سیگمنٹیشن صحیح طریقے سے کام کر رہا ہے۔

# Install the Hubble CLI
export HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
tar xzvf hubble-linux-amd64.tar.gz
sudo mv hubble /usr/local/bin/

# Port-forward to the Hubble relay
kubectl port-forward -n kube-system svc/hubble-relay 4245:80 &

# Show all flows in the production namespace from the last hour
hubble observe --namespace production --since 1h

# Show only dropped flows — proves policies are blocking unauthorised traffic
hubble observe --namespace production --verdict DROPPED --since 1h

ہبل آؤٹ پٹ کی مثال بلاک شدہ کنکشن کی کوششیں دکھا رہی ہے:

Apr 19 03:17:41.234   DROPPED   TCP   10.244.1.5:52341 → 10.244.1.4:5432   policy-deny
Apr 19 03:17:41.235   ALLOWED   TCP   10.244.1.2:43211 → 10.244.1.4:5432   allow-same-namespace

پہلی لائن غیر مجاز کنکشن کی کوششوں کو دکھاتی ہے جو بلاک کر دی گئی ہیں۔ دوسرا شو جائز کنکشن کی اجازت دیتا ہے. یہ لاگز روزانہ SOC2 ثبوت بالٹی میں برآمد کیے جاتے ہیں۔

یاد رکھنے کا ایک اصول: ڈیفالٹ انکار صفر ٹرسٹ کا معیار ہے۔ پھر تمام مطلوبہ مواصلاتی راستوں کے لیے واضح اجازت کے اصول شامل کریں۔ ہبل ثبوت فراہم کرتا ہے کہ یہ کام کرتا ہے۔

حصہ 5: CNI موازنہ — Cilium, Calico, AWS VPC CNI

صحیح CNI کا انتخاب ایک ایسا فیصلہ ہے جس کو تبدیل کرنا مشکل ہے۔ CNIs کے درمیان منتقلی کے لیے کلسٹر میں تمام نوڈس کو خالی کرنے اور تبدیل کرنے کی ضرورت ہوتی ہے۔ ایک بار اور تمام صحیح وجوہات کی بناء پر فیصلہ کریں۔

یہاں خصوصیات کا حقیقی دنیا کا موازنہ ہے جو پروڈکشن EKS کلسٹر کے لیے اہم ہیں:

صلاحیت AWS VPC CNI کیلیکو پلکیں
VPC CIDR میں Pod IP ہاں نہیں (اوورلے نیٹ ورک) نہیں (اوورلے نیٹ ورک)
ڈیفالٹ نیٹ ورک پالیسی ہاں (Kubernetes سٹینڈرڈ) ہاں ہاں
پرت 7 پالیسیاں (HTTP روٹس، gRPC طریقے) نہیں نہیں ہاں
ای بی پی ایف ڈیٹا پلین نہیں نہیں ہاں
ہبل سٹریم آبزرویبلٹی نہیں نہیں ہاں
سروس میش (سائیڈ کار کے بغیر ایم ٹی ایل ایس) نہیں نہیں ہاں
بلٹ ان SOC2 نیٹ ورک شواہد نہیں نہیں ہاں (ہبل)
کارکردگی اوور ہیڈ کم درمیانی بہت کم (eBPF iptable کو نظرانداز کرتا ہے)
AWS مقامی انٹیگریشن بہترین درمیانی درمیانی

تجویز میٹرکس:

آپ کی حالت تجویز کردہ CNI
سادہ EKS کلسٹر، AWS پر مبنی ٹولز، کوئی جدید پالیسی نہیں۔ AWS VPC CNI
نیٹ ورک پالیسی کی ضرورت ہے، لیکن کوئی پرت 7 یا مشاہدہ نہیں ہے۔ کیلیکو
پوڈ کی سطح کی تنہائی کے ثبوت کے ساتھ SOC2 کی تعمیل کی ضرورت ہے۔ پلکیں
آپ کو سائڈ کار پراکسی اوور ہیڈ کے بغیر سروس میش کی ضرورت ہے۔ پلکیں
لیئر 7 نیٹ ورک پالیسی کی ضرورت ہے (GET/health کی اجازت دیں، POST/admin سے انکار کریں) پلکیں

یاد رکھنے کے لیے ایک اصول: EKS میں SOC2 کی تعمیل اور صفر ٹرسٹ نیٹ ورکنگ کے لیے، Cilium صحیح انتخاب ہے۔ پوڈ لیول آئسولیشن، پرت 7 پالیسیاں، اور آڈٹ ثبوت کے طور پر استعمال ہونے والے ہبل فلو لاگز فراہم کرتا ہے۔ یہ ایک ایسی خصوصیت ہے جس کے ساتھ کوئی دوسرا CNI نہیں آتا ہے۔

حصہ 6: سروس میش — Cilium بمقابلہ Istio بمقابلہ Linkerd

6.1 سروس میش کیا فراہم کرتا ہے۔

سروس میش کلسٹر نیٹ ورکنگ میں تین خصوصیات کا اضافہ کرتا ہے جو کوبرنیٹس مقامی طور پر فراہم نہیں کرتا ہے:

باہمی TLS (mTLS) خدمات کے کسی بھی جوڑے کے درمیان مواصلات کو خفیہ کرتا ہے اور دونوں فریقوں کی شناخت کی تصدیق کرتا ہے۔ ایم ٹی ایل ایس کے بغیر، ادائیگی کی خدمت اور ڈیٹا بیس کے درمیان ٹریفک کلسٹر کے اندر واضح متن میں سفر کرتی ہے۔

ٹریفک مشاہدہ تمام کراس سروس کالز کے لیے درخواست کی شرحوں، تاخیر کے پرسنٹائلز، اور خرابی کی شرحوں کو ٹریک کرکے آپ کی درخواست کا حقیقی وقت کی کارکردگی کا نقشہ فراہم کرتا ہے۔

ٹریفک مینجمنٹ کنٹرول کرتی ہے کہ ٹریفک کیسے چلتی ہے، بشمول ناکامیوں پر دوبارہ کوششیں، ٹائم آؤٹ، ڈاون اسٹریم سروسز کے کم ہونے پر سرکٹ بلاک کرنا، اور کینری تعیناتیوں کے لیے ٹریفک کی تقسیم۔

6.2 سائیڈ کار کا مسئلہ

موجودہ سروس میشز جیسے Istio اور Linkerd ہر Pod میں ایک سائڈ کار پراکسی کنٹینر ڈالتے ہیں۔ یہ سائڈ کار تمام نیٹ ورک ٹریفک کو روکتا ہے اور میش پالیسیوں کو نافذ کرتا ہے۔ مسئلہ وسائل اوور ہیڈ کا ہے۔ Istio’s Envoy sidecar تقریباً 128MB میموری فی پوڈ اور 5-10% لیٹنسی اوور ہیڈ کا اضافہ کرتا ہے۔

200 پوڈز والے کلسٹر میں، Istio sidecar ہر سروس کال میں 25.6 GB میموری اوور ہیڈ اور قابل پیمائش تاخیر کا اضافہ کرتا ہے۔

Cilium اسے مختلف طریقے سے حل کرتا ہے۔ سائیڈ کار کے بغیر ای بی پی ایف کا استعمال کرتے ہوئے کرنل لیول پر سروس میش لگائیں۔

6.3 مجموعی موازنہ

صلاحیت پلکیں اس پر چھوڑ دیا
سائیڈ کار کی ضرورت ہے۔ نہیں (eBPF کرنل) ہاں (ایلچی، ~128MB/pod) ہاں (رسٹ پراکسی، ~10MB/pod)
میموری اوور ہیڈ فی پوڈ 0MB ~128MB ~10MB
اوور ہیڈ میں تاخیر <1% 5-10% 2~3%
mTLS ہاں ہاں ہاں
ٹریفک مینجمنٹ (کینریز، سرکٹ بلاکنگ) محدود تمام تمام
بلٹ ان بہاؤ مشاہدہ (ہبل) ہاں کیالی کی ضرورت ہے۔ بویانسی کلاؤڈ کی ضرورت ہے۔
SOC2 ثبوت بطور ڈیفالٹ ہاں اضافی ٹولز اضافی ٹولز
سیٹ اپ کی پیچیدگی کم اعلی درمیانی

تجویز میٹرکس:

آپ کی حالت تجویز کردہ سروس میش
کم سے کم وسائل اوور ہیڈ کے ساتھ mTLS اور SOC2 ثبوت کی ضرورت ہے۔ پلکیں
اعلی درجے کی ٹریفک مینجمنٹ کی ضرورت ہے: کینریز، سرکٹ بریکنگ، وزنی روٹنگ اس پر
آپ کو Istio کی آپریشنل پیچیدگی کے بغیر ہلکے وزن والے mTLS کی ضرورت ہے۔ چھوڑ دیا
سیکڑوں پوڈز کے ساتھ کلسٹر چلانا جہاں سائیڈ کار اوور ہیڈ بجٹ کا مسئلہ ہے۔ پلکیں

Cilium کے سروس میش موڈ کو فعال کریں (سائیڈ کار کی ضرورت نہیں):

# Upgrade your Cilium installation to enable service mesh features
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set envoy.enabled=true \
  --set ingressController.enabled=true

# Verify the service mesh is active
cilium status | grep "Service Mesh"

یاد رکھنے کا ایک اصول: Cilium بغیر سائڈ کار اوور ہیڈ کے mTLS اور SOC2 ثبوت فراہم کرتا ہے۔ ان ٹیموں کے لیے جنہیں ٹریفک مینجمنٹ یا پیچیدہ کینری ریلیز پیٹرن کی ضرورت ہوتی ہے، Istio آپریشنل پیچیدگی میں اضافے کی قیمت پر مزید کنٹرول فراہم کرتا ہے۔

Kubernetes نیٹ ورکنگ کے بہترین طریقے

کرنا: Pod IPs کے علاوہ دیگر خدمات استعمال کریں۔ پوڈ IP ہر دوبارہ شروع ہونے پر تبدیل ہوتا ہے۔ سروس DNS کا نام کبھی تبدیل نہیں ہوتا ہے۔

کرنا: روٹ پر مبنی روٹنگ کے ساتھ ایک واحد انگریس کنٹرولر استعمال کریں۔ ایک ALB تمام خدمات فراہم کرتا ہے اور لوڈ بیلنس فی سروس کے مقابلے میں ہر ماہ $300 سے $400 کی بچت کرتا ہے۔

کرنا: Cilium کا استعمال کرتے ہوئے ڈیفالٹ انکار نیٹ ورک پالیسی کو نافذ کریں۔ یہ ایک تکنیکی کنٹرول ہے جو SOC2 CC6.1 کو درکار ہے۔

کرنا: ہبل فلو لاگز کو SOC2 ثبوت کے طور پر استعمال کریں۔ ڈیلیٹ شدہ فلو لاگز کو ہر روز ثبوت کی بالٹی میں ایکسپورٹ کریں۔

کرنا: انکرپٹڈ انٹر سروس کمیونیکیشن کے لیے Cilium کے ساتھ mTLS کو فعال کریں۔ سائڈ کار کی ضرورت نہیں ہے۔

کرنا: ٹریفک کو ایک ہی Availability Zone کے اندر رکھنے اور AZs کے درمیان ڈیٹا کی منتقلی کے اخراجات کو کم کرنے کے لیے ٹاپولوجی سے آگاہ روٹنگ کا استعمال کریں۔

مت کرو: ہر مائیکرو سروس کے لیے لوڈ بیلنسر سروس بنائیں۔ بیرونی روٹنگ کے لیے، ہم Ingress استعمال کرتے ہیں۔

مت کرو: پوڈ لیول آئسولیشن کے لیے صرف سیکیورٹی گروپس پر بھروسہ کریں۔ سیکورٹی گروپ نوڈ لیول پر کام کرتے ہیں۔ نوڈ پر موجود تمام پوڈز نوڈ کے سیکیورٹی گروپ کو شیئر کرتے ہیں۔ نیٹ ورک کی پالیسیاں پوڈ کی سطح پر کام کرتی ہیں۔

مت کرو: پہلے سے طے شدہ "Allow All” پوڈ نیٹ ورکنگ کو محفوظ سمجھا جاتا ہے۔ پہلے سے طے شدہ انکار کا اطلاق کریں اس سے پہلے کہ آپ کا پہلا انٹرپرائز کسٹمر نیٹ ورک سیگمنٹیشن ڈایاگرام کی درخواست کرے۔

وسائل

متعلقہ پوسٹس

اوپر تک سکرول کریں۔