کبرنیٹس میں نیٹ ورکنگ کے لیے کیلیکو: ایک تعارف اور تھوڑا سا تجربہ

مضمون کا مقصد قارئین کو Kubernetes میں نیٹ ورکنگ اور نیٹ ورک کی پالیسیوں کے انتظام کی بنیادی باتوں کے ساتھ ساتھ تھرڈ پارٹی کیلیکو پلگ ان سے متعارف کرانا ہے جو معیاری صلاحیتوں کو بڑھاتا ہے۔ راستے میں، ہمارے آپریٹنگ تجربے سے حقیقی مثالوں کا استعمال کرتے ہوئے ترتیب کی آسانی اور کچھ خصوصیات کا مظاہرہ کیا جائے گا۔

Kubernetes نیٹ ورکنگ آلات کا ایک فوری تعارف

نیٹ ورک کے بغیر Kubernetes کلسٹر کا تصور نہیں کیا جا سکتا۔ ہم پہلے ہی ان کی بنیادی باتوں پر مواد شائع کر چکے ہیں:Kubernetes میں نیٹ ورکنگ کے لیے ایک واضح گائیڈ"اور"سیکورٹی پروفیشنلز کے لیے Kubernetes نیٹ ورک کی پالیسیوں کا ایک تعارف'.

اس مضمون کے تناظر میں، یہ نوٹ کرنا ضروری ہے کہ K8s خود کنٹینرز اور نوڈس کے درمیان نیٹ ورک کنیکٹیویٹی کے لیے ذمہ دار نہیں ہے: اس کے لیے، مختلف CNI پلگ انز (کنٹینر نیٹ ورکنگ انٹرفیس)۔ اس تصور کے بارے میں مزید ہم انہوں نے مجھے بھی بتایا.

مثال کے طور پر، ان پلگ ان میں سب سے زیادہ عام ہے۔ فلالین - تمام کلسٹر نوڈس کے درمیان مکمل نیٹ ورک کنیکٹیویٹی فراہم کرتا ہے ہر نوڈ پر پل بڑھا کر، اس کو سب نیٹ تفویض کر کے۔ تاہم، مکمل اور غیر منظم رسائی ہمیشہ فائدہ مند نہیں ہوتی۔ کلسٹر میں کسی قسم کی کم سے کم تنہائی کو یقینی بنانے کے لیے، فائر وال کی ترتیب میں مداخلت کرنا ضروری ہے۔ عام صورت میں، اسے اسی CNI کے کنٹرول میں رکھا جاتا ہے، یہی وجہ ہے کہ iptables میں فریق ثالث کی مداخلت کی غلط تشریح کی جا سکتی ہے یا اسے یکسر نظر انداز کیا جا سکتا ہے۔

اور Kubernetes کلسٹر میں نیٹ ورک پالیسی مینجمنٹ کو منظم کرنے کے لیے "آؤٹ آف دی باکس" فراہم کیا گیا ہے۔ نیٹ ورک پالیسی API. یہ وسیلہ، منتخب کردہ نام کی جگہوں پر تقسیم کیا گیا ہے، اس میں ایک ایپلیکیشن سے دوسری تک رسائی میں فرق کرنے کے اصول شامل ہو سکتے ہیں۔ یہ آپ کو مخصوص پوڈز، ماحولیات (نام کی جگہوں) یا IP پتوں کے بلاکس کے درمیان رسائی کو ترتیب دینے کی بھی اجازت دیتا ہے:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

یہ اس کی سب سے قدیم مثال نہیں ہے۔ سرکاری دستاویزات نیٹ ورک کی پالیسیاں کیسے کام کرتی ہیں اس کی منطق کو سمجھنے کی خواہش کی حوصلہ شکنی کر سکتا ہے۔ تاہم، ہم پھر بھی نیٹ ورک کی پالیسیوں کا استعمال کرتے ہوئے ٹریفک کے بہاؤ پر کارروائی کرنے کے بنیادی اصولوں اور طریقوں کو سمجھنے کی کوشش کریں گے...

یہ منطقی ہے کہ ٹریفک کی 2 قسمیں ہیں: پوڈ میں داخل ہونا (انگریس) اور اس سے باہر جانا (ایگریس)۔

دراصل سیاست کو تحریک کی سمت کی بنیاد پر ان 2 زمروں میں تقسیم کیا گیا ہے۔

اگلی مطلوبہ صفت سلیکٹر ہے؛ وہ جس پر اصول لاگو ہوتا ہے۔ یہ پوڈ (یا پھلیوں کا ایک گروپ) یا ماحول (یعنی نام کی جگہ) ہو سکتا ہے۔ ایک اہم تفصیل: ان اشیاء کی دونوں اقسام میں ایک لیبل ہونا ضروری ہے (لیبل Kubernetes اصطلاحات میں) - یہ وہ ہیں جن کے ساتھ سیاست دان کام کرتے ہیں۔

کسی نہ کسی قسم کے لیبل کے ذریعے متحد ہونے والے منتخب کنندگان کی محدود تعداد کے علاوہ، مختلف تغیرات میں "Allow/deny everything/everyone" جیسے اصول لکھنا ممکن ہے۔ اس مقصد کے لئے، فارم کی تعمیرات کا استعمال کیا جاتا ہے:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

— اس مثال میں، ماحول میں تمام پوڈز کو آنے والی ٹریفک سے روک دیا گیا ہے۔ مندرجہ ذیل تعمیر کے ساتھ مخالف طرز عمل حاصل کیا جا سکتا ہے:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

اسی طرح آؤٹ گوئنگ کے لیے:

  podSelector: {}
  policyTypes:
  - Egress

- اسے بند کرنے کے لئے. اور یہاں کیا شامل کرنا ہے:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

کلسٹر کے لیے CNI پلگ ان کے انتخاب پر واپس جانا، یہ بات قابل غور ہے۔ ہر نیٹ ورک پلگ ان نیٹ ورک پالیسی کو سپورٹ نہیں کرتا ہے۔. مثال کے طور پر، پہلے ہی ذکر کردہ فلالین نیٹ ورک کی پالیسیوں کو ترتیب دینے کا طریقہ نہیں جانتا ہے، جو یہ براہ راست کہا جاتا ہے سرکاری ذخیرے میں۔ وہاں ایک متبادل کا بھی ذکر کیا گیا ہے - ایک اوپن سورس پروجیکٹ کیلیکو۔، جو نیٹ ورک کی پالیسیوں کے لحاظ سے Kubernetes APIs کے معیاری سیٹ کو نمایاں طور پر پھیلاتا ہے۔

کیلیکو کو جاننا: تھیوری

کیلیکو پلگ ان کو فلالین کے ساتھ انضمام میں استعمال کیا جا سکتا ہے (سب پروجیکٹ چینل) یا آزادانہ طور پر، نیٹ ورک کنیکٹیویٹی اور دستیابی کے انتظام کی صلاحیتوں دونوں کا احاطہ کرتا ہے۔

K8s "باکسڈ" حل اور Calico سے API سیٹ کا استعمال کیا مواقع فراہم کرتا ہے؟

نیٹ ورک پالیسی میں جو کچھ بنایا گیا ہے وہ یہ ہے:

• سیاست دان ماحول سے محدود ہوتے ہیں۔
• پالیسیاں لیبل کے ساتھ نشان زد پوڈز پر لاگو ہوتی ہیں۔
• اصول پوڈز، ماحولیات یا ذیلی نیٹ پر لاگو کیے جا سکتے ہیں۔
• قواعد میں پروٹوکول، نام یا علامتی بندرگاہ کی وضاحتیں شامل ہوسکتی ہیں۔

یہاں ہے کہ کیلیکو ان افعال کو کیسے بڑھاتا ہے:

• پالیسیاں کسی بھی چیز پر لاگو کی جا سکتی ہیں: پوڈ، کنٹینر، ورچوئل مشین یا انٹرفیس؛
• قواعد میں ایک مخصوص کارروائی شامل ہوسکتی ہے (ممانعت، اجازت، لاگنگ)؛
• اصولوں کا ہدف یا ذریعہ ایک بندرگاہ، بندرگاہوں کی ایک رینج، پروٹوکول، HTTP یا ICMP کی خصوصیات، IP یا سب نیٹ (چوتھی یا چھٹی نسل)، کوئی بھی سلیکٹر (نوڈ، میزبان، ماحول) ہو سکتا ہے؛
• مزید برآں، آپ DNAT سیٹنگز اور ٹریفک فارورڈنگ پالیسیوں کا استعمال کرتے ہوئے ٹریفک کے گزرنے کو ریگولیٹ کر سکتے ہیں۔

کیلیکو ریپوزٹری میں GitHub پر پہلی کمٹمنٹ جولائی 2016 کی ہے، اور ایک سال بعد پروجیکٹ نے Kubernetes نیٹ ورک کنیکٹیویٹی کو منظم کرنے میں ایک اہم مقام حاصل کیا - اس کا ثبوت مثال کے طور پر، سروے کے نتائج سے ملتا ہے، دی نیو اسٹیک کے ذریعہ منعقد کیا گیا۔:

K8s کے ساتھ بہت سے بڑے منظم حل، جیسے ایمیزون ای کے ایس, Azure AKS, گوگل جی کے ای اور دوسروں نے اسے استعمال کے لیے تجویز کرنا شروع کیا۔

کارکردگی کے طور پر، یہاں سب کچھ بہت اچھا ہے. اپنے پروڈکٹ کی جانچ میں، کیلیکو ڈیولپمنٹ ٹیم نے فلکیاتی کارکردگی کا مظاہرہ کیا، 50000 فزیکل نوڈس پر 500 سے زیادہ کنٹینرز چلاتے ہوئے 20 کنٹینرز فی سیکنڈ کی تخلیق کی شرح کے ساتھ۔ اسکیلنگ کے ساتھ کسی بھی مسئلے کی نشاندہی نہیں کی گئی۔ ایسے نتائج اعلان کیا گیا تھا پہلے ہی پہلے ورژن کے اعلان پر۔ تھرو پٹ اور وسائل کی کھپت پر توجہ مرکوز کرنے والے آزاد مطالعہ بھی اس بات کی تصدیق کرتے ہیں کہ کیلیکو کی کارکردگی تقریباً اتنی ہی اچھی ہے جتنی فلانیل کی ہے۔ مثال کے طور پر:

پروجیکٹ بہت تیزی سے ترقی کر رہا ہے، یہ K8s، OpenShift، OpenStack کے زیر انتظام مقبول حلوں میں کام کی حمایت کرتا ہے، کلسٹر کو استعمال کرتے وقت کیلیکو کو استعمال کرنا ممکن ہے۔ لات مارناسروس میش نیٹ ورکس کی تعمیر کے حوالے موجود ہیں (یہاں ایک مثال ہے Istio کے ساتھ مل کر استعمال کیا جاتا ہے)۔

کیلیکو کے ساتھ مشق کریں۔

ونیلا کبرنیٹس کے استعمال کے عمومی معاملے میں، CNI انسٹال کرنا فائل کو استعمال کرنے پر آتا ہے۔ calico.yaml, سرکاری ویب سائٹ سے ڈاؤن لوڈ کیا گیا۔، کے ذریعے kubectl apply -f.

ایک اصول کے طور پر، پلگ ان کا موجودہ ورژن Kubernetes کے تازہ ترین 2-3 ورژن کے ساتھ مطابقت رکھتا ہے: پرانے ورژن میں آپریشن کا تجربہ نہیں کیا جاتا ہے اور اس کی کوئی ضمانت نہیں ہے۔ ڈویلپرز کے مطابق، کیلیکو iptables یا IPVS کے اوپری حصے پر، CentOS 3.10، Ubuntu 7 یا Debian 16 پر چلنے والے 8 سے اوپر کے لینکس کرنل پر چلتا ہے۔

ماحول کے اندر تنہائی

ایک عام فہم کے لیے، آئیے یہ سمجھنے کے لیے ایک سادہ کیس کو دیکھتے ہیں کہ کیلیکو اشارے میں نیٹ ورک کی پالیسیاں معیاری پالیسیوں سے کس طرح مختلف ہیں اور قواعد بنانے کا طریقہ ان کی پڑھنے کی اہلیت اور ترتیب کی لچک کو کیسے آسان بناتا ہے:

کلسٹر میں 2 ویب ایپلیکیشنز تعینات ہیں: Node.js اور PHP میں، جن میں سے ایک Redis استعمال کرتی ہے۔ PHP سے Redis تک رسائی کو روکنے کے لیے، Node.js کے ساتھ رابطے کو برقرار رکھتے ہوئے، صرف درج ذیل پالیسی کا اطلاق کریں:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

بنیادی طور پر ہم نے Node.js سے Redis پورٹ پر آنے والی ٹریفک کی اجازت دی۔ اور انہوں نے واضح طور پر کسی اور چیز کو منع نہیں کیا۔ جیسے ہی نیٹ ورک پالیسی ظاہر ہوتی ہے، اس میں مذکور تمام سلیکٹرز الگ تھلگ ہونے لگتے ہیں، جب تک کہ دوسری صورت میں اس کی وضاحت نہ کی جائے۔ تاہم، الگ تھلگ قوانین دیگر اشیاء پر لاگو نہیں ہوتے ہیں جن کا سلیکٹر کے ذریعے احاطہ نہیں کیا جاتا ہے۔

مثال استعمال کرتا ہے۔ apiVersion باکس سے باہر Kubernetes، لیکن کوئی بھی چیز آپ کو اسے استعمال کرنے سے نہیں روکتی کیلیکو ڈیلیوری سے اسی نام کا وسیلہ. وہاں کا نحو زیادہ مفصل ہے، اس لیے آپ کو مندرجہ بالا صورت کے لیے اصول کو درج ذیل شکل میں دوبارہ لکھنا ہو گا۔

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

ریگولر NetworkPolicy API کے ذریعے تمام ٹریفک کی اجازت دینے یا انکار کرنے کے لیے مذکورہ بالا تعمیرات قوسین کے ساتھ تعمیرات پر مشتمل ہیں جنہیں سمجھنا اور یاد رکھنا مشکل ہے۔ کیلیکو کے معاملے میں، فائر وال کے اصول کی منطق کو اس کے برعکس تبدیل کرنے کے لیے، صرف تبدیل کریں action: Allow پر action: Deny.

ماحول کے لحاظ سے تنہائی

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

Prometheus، ایک اصول کے طور پر، ایک علیحدہ سروس ماحول میں رکھا جاتا ہے - مثال کے طور پر یہ نام کی جگہ اس طرح ہوگی:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

فیلڈ metadata.labels یہ کوئی حادثہ نہیں نکلا۔ جیسا کہ اوپر درج ہے، namespaceSelector (اس کے ساتھ ساتھ podSelector) لیبل کے ساتھ کام کرتا ہے۔ لہذا، ایک مخصوص پورٹ پر تمام پوڈز سے میٹرکس لینے کی اجازت دینے کے لیے، آپ کو کسی قسم کا لیبل شامل کرنا ہوگا (یا موجودہ سے لینا ہوگا)، اور پھر کنفیگریشن کو لاگو کرنا ہوگا جیسے:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

اور اگر آپ کیلیکو پالیسیاں استعمال کرتے ہیں تو نحو اس طرح ہو گا:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

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

کیلیکو کے تخلیق کاروں کے مطابق، بہترین عمل ہے "ہر چیز کو مسدود کریں اور اپنی ضرورت کو واضح طور پر کھولیں" نقطہ نظر، جس میں دستاویزی سرکاری دستاویزات (دوسرے بھی اسی طرح کے نقطہ نظر کی پیروی کرتے ہیں - خاص طور پر، میں پہلے ہی ذکر شدہ مضمون).

اضافی کیلیکو آبجیکٹ کا استعمال

میں آپ کو یاد دلاتا ہوں کہ Calico APIs کے توسیعی سیٹ کے ذریعے آپ نوڈس کی دستیابی کو ریگولیٹ کر سکتے ہیں، نہ کہ pods تک محدود۔ مندرجہ ذیل مثال میں استعمال کرتے ہوئے GlobalNetworkPolicy کلسٹر میں آئی سی ایم پی کی درخواستوں کو منتقل کرنے کی صلاحیت بند ہے (مثال کے طور پر، پوڈ سے نوڈ تک، پوڈ کے درمیان، یا نوڈ سے آئی پی پوڈ پر پنگ):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

مذکورہ صورت میں، کلسٹر نوڈس کے لیے ICMP کے ذریعے ایک دوسرے تک "پہنچنا" اب بھی ممکن ہے۔ اور اس مسئلے کو ذرائع سے حل کیا جاتا ہے۔ GlobalNetworkPolicy، ایک ہستی پر لاگو کیا گیا۔ HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

وی پی این کیس

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

کلائنٹ معیاری UDP پورٹ 1194 کے ذریعے VPN سے جڑتے ہیں اور جب منسلک ہوتے ہیں تو پوڈز اور سروسز کے کلسٹر سب نیٹس کے راستے حاصل کرتے ہیں۔ پورے ذیلی نیٹ کو آگے بڑھایا جاتا ہے تاکہ دوبارہ شروع کرنے اور پتے تبدیل کرنے پر خدمات ضائع نہ ہوں۔

کنفیگریشن میں پورٹ معیاری ہے، جو ایپلیکیشن کو کنفیگر کرنے اور اسے Kubernetes کلسٹر میں منتقل کرنے کے عمل پر کچھ باریکیاں عائد کرتی ہے۔ مثال کے طور پر، اسی AWS LoadBlancer میں UDP کے لیے پچھلے سال کے آخر میں خطوں کی ایک محدود فہرست میں لفظی طور پر ظاہر ہوا، اور NodePort کو تمام کلسٹر نوڈس پر فارورڈ کرنے کی وجہ سے استعمال نہیں کیا جا سکتا اور سرور کی مثالوں کی تعداد کو پیمانہ کرنا ناممکن ہے۔ غلطی رواداری کے مقاصد اس کے علاوہ، آپ کو بندرگاہوں کی ڈیفالٹ رینج کو تبدیل کرنا پڑے گا...

ممکنہ حل تلاش کرنے کے نتیجے میں، درج ذیل کا انتخاب کیا گیا:

1. وی پی این کے ساتھ پوڈز فی نوڈ میں شیڈول کیے گئے ہیں۔ hostNetwork، یعنی اصل IP پر۔
2. سروس کے ذریعے باہر پوسٹ کیا جاتا ہے۔ ClusterIP. نوڈ پر ایک پورٹ فزیکل طور پر انسٹال ہوتا ہے، جو باہر سے معمولی تحفظات (اصلی IP ایڈریس کی مشروط موجودگی) کے ساتھ قابل رسائی ہے۔
3. اس نوڈ کا تعین کرنا جس پر پھلی گلاب ہے ہماری کہانی کے دائرہ کار سے باہر ہے۔ میں صرف یہ کہوں گا کہ آپ سروس کو کسی نوڈ پر ہارڈ وائر کر سکتے ہیں یا ایک چھوٹی سائڈ کار سروس لکھ سکتے ہیں جو VPN سروس کے موجودہ IP ایڈریس کی نگرانی کرے گی اور کلائنٹس کے ساتھ رجسٹرڈ DNS ریکارڈز میں ترمیم کرے گی - جس کے پاس کافی تخیل ہے۔

روٹنگ کے نقطہ نظر سے، ہم VPN سرور کے ذریعہ جاری کردہ IP ایڈریس کے ذریعہ VPN کلائنٹ کی منفرد شناخت کر سکتے ہیں۔ ذیل میں اس طرح کے کلائنٹ کی خدمات تک رسائی کو محدود کرنے کی ایک ابتدائی مثال دی گئی ہے، جس کی مثال مذکورہ Redis پر دی گئی ہے:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

یہاں، پورٹ 6379 سے منسلک ہونا سختی سے ممنوع ہے، لیکن ایک ہی وقت میں DNS سروس کے آپریشن کو محفوظ کیا جاتا ہے، جس کے کام کو اکثر قواعد تیار کرتے وقت متاثر ہوتا ہے. کیونکہ، جیسا کہ پہلے ذکر کیا گیا ہے، جب کوئی سلیکٹر ظاہر ہوتا ہے، ڈیفالٹ انکار پالیسی اس پر لاگو ہوتی ہے جب تک کہ دوسری صورت میں وضاحت نہ کی جائے۔

کے نتائج

اس طرح، Calico کے جدید API کا استعمال کرتے ہوئے، آپ لچکدار طریقے سے ترتیب دے سکتے ہیں اور کلسٹر کے اندر اور اس کے ارد گرد روٹنگ کو متحرک طور پر تبدیل کر سکتے ہیں۔ عام طور پر، اس کا استعمال ایک توپ سے چڑیوں کو گولی مارنے کی طرح نظر آتا ہے، اور BGP اور IP-IP سرنگوں کے ساتھ L3 نیٹ ورک کو لاگو کرنا فلیٹ نیٹ ورک پر سادہ Kubernetes انسٹالیشن میں خوفناک لگتا ہے۔ .

سیکورٹی کے تقاضوں کو پورا کرنے کے لیے کلسٹر کو الگ تھلگ کرنا ہمیشہ ممکن نہیں ہوتا، اور یہ وہ جگہ ہے جہاں Calico (یا اسی طرح کا حل) بچاؤ کے لیے آتا ہے۔ اس مضمون میں دی گئی مثالیں (معمولی ترمیم کے ساتھ) AWS میں ہمارے کلائنٹس کی کئی تنصیبات میں استعمال ہوتی ہیں۔

PS

ہمارے بلاگ پر بھی پڑھیں:

• «سیکورٹی پروفیشنلز کے لیے Kubernetes نیٹ ورک کی پالیسیوں کا ایک تعارف؛ "
• "کوبرنیٹس میں نیٹ ورکنگ کے لیے ایک مصوری گائیڈ": حصے 1 اور 2 (نیٹ ورک ماڈل، اوورلے نیٹ ورکس), حصہ 3 (سروسز اور ٹریفک پروسیسنگ);
• «کنٹینر نیٹ ورکنگ انٹرفیس (CNI) - لینکس کنٹینرز کے لیے نیٹ ورک انٹرفیس اور معیاری'.

ماخذ: www.habr.com