ProHoster > بلاګ > اداره > کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

د مقالې هدف دا دی چې لوستونکي ته په کوبرنیټس کې د شبکې تګلارې او مدیریت کولو اساساتو ته معرفي کړي ، په بیله بیا د دریمې ډلې کالیکو پلگ ان چې معیاري وړتیاوې غزوي. د لارې په اوږدو کې، د ترتیب کولو اسانتیا او ځینې ځانګړتیاوې به زموږ د عملیاتي تجربې څخه د اصلي مثالونو په کارولو سره وښودل شي.

د Kubernetes شبکې وسیلې ته ګړندۍ پیژندنه

د Kubernetes کلستر د شبکې پرته تصور نشي کیدی. موږ دمخه د دوی د اساساتو په اړه مواد خپاره کړي دي: "په Kubernetes کې د شبکې کولو لپاره یو روښانه لارښود"او"د امنیتي مسلکیانو لپاره د کوبرنیټس شبکې پالیسیو پیژندنه".

د دې مقالې په شرایطو کې، دا مهمه ده چې یادونه وکړو چې K8s پخپله د کانټینرونو او نوډونو ترمنځ د شبکې ارتباط مسولیت نلري: د دې لپاره، مختلف د CNI پلگ ان (د کانټینر شبکې انٹرفیس). د دې مفهوم په اړه نور موږ دوی ماته هم وویل.

د مثال په توګه، د دې پلگ ان تر ټولو عام دی فلالین - په هر نوډ کې د پلونو په پورته کولو سره د ټولو کلستر نوډونو ترمنځ د شبکې بشپړ ارتباط چمتو کوي، دې ته د فرعي نیټ په ورکولو سره. په هرصورت، بشپړ او غیر منظم لاسرسي تل ګټور نه وي. د دې لپاره چې په کلستر کې یو څه لږترلږه انزوا یقیني شي، دا اړینه ده چې د اور وژنې په ترتیب کې مداخله وشي. په عمومي حالت کې، دا د ورته CNI کنټرول لاندې ساتل کیږي، له همدې امله په iptables کې د دریمې ډلې مداخلې په غلط ډول تشریح کیدی شي یا په بشپړه توګه له پامه غورځول کیدی شي.

او د کوبرنیټس کلستر کې د شبکې پالیسۍ مدیریت تنظیم کولو لپاره "د بکس څخه بهر" چمتو شوی د شبکې پالیسي 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

دا تر ټولو لومړنۍ بېلګه نه ده رسمي اسناد کیدای شي یو ځل او د ټولو لپاره د شبکې د پالیسیو د کار کولو په منطق باندې پوهیدو لیوالتیا وهڅوي. په هرصورت، موږ به بیا هم هڅه وکړو چې د شبکې پالیسیو په کارولو سره د ټرافيکو جریانونو پروسس کولو اساسي اصولو او میتودونو پوه شو ...

دا منطقي ده چې دوه ډوله ترافیک شتون لري: پوډ ته ننوتل (انګریس) او له هغې څخه وتل (ایګریس).

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

په حقیقت کې، سیاست د حرکت د سمت پر بنسټ په دې دوو کټګوریو ویشل شوی دی.

راتلونکی اړین ځانګړتیا یو انتخاب کونکی دی؛ هغه څوک چې قانون پلي کیږي. دا کیدای شي یو پوډ (یا د پوډونو ډله) یا چاپیریال (د بیلګې په توګه د نوم ځای). یو مهم تفصیل: د دې شیانو دواړه ډولونه باید یو لیبل ولري (د لیبل د Kubernetes په اصطلاح کې) - دا هغه څه دي چې سیاستوال ورسره کار کوي.

د یو محدود شمیر انتخاب کونکو سربیره ، د یو ډول لیبل لخوا متحد شوي ، دا ممکنه ده چې قواعد ولیکئ لکه "هر څه ته اجازه ورکړئ / هرچا ته اجازه ورکړئ" په مختلف توپیرونو کې. د دې هدف لپاره، د فارم جوړښت کارول کیږي:

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

- په دې مثال کې، په چاپیریال کې ټول پوډونه د راتلونکی ټرافیک څخه بند شوي دي. برعکس چلند د لاندې جوړښت سره ترلاسه کیدی شي:

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

په ورته ډول د وتلو لپاره:

  podSelector: {}
  policyTypes:
  - Egress

- د بندولو لپاره. او دلته هغه څه دي چې پکې شامل دي:

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

د کلستر لپاره د CNI پلگ ان انتخاب ته راستنیدل، دا د یادولو وړ ده د شبکې هر پلگ ان د شبکې پالیسي ملاتړ نه کوي. د مثال په توګه، مخکې ذکر شوي فلانیل نه پوهیږي چې څنګه د شبکې پالیسۍ تنظیم کړي، کوم چې دا په مستقیم ډول ویل کیږي په رسمي ذخیره کې. یو بدیل هم دلته ذکر شوی - د خلاصې سرچینې پروژه کلیکو، کوم چې د شبکې پالیسیو په شرایطو کې د Kubernetes APIs معیاري سیټ د پام وړ پراخوي.

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

د کالیکو پیژندل: ​​تیوري

د کالیکو پلگ ان د فلانیل سره په ادغام کې کارول کیدی شي (فرعي پروژه د کانال) یا په خپلواکه توګه، د شبکې ارتباط او د شتون مدیریت وړتیا دواړه پوښي.

د K8s "بکس شوي" حل او د کالیکو څخه ټاکل شوي API کارول کوم فرصتونه چمتو کوي؟

دلته هغه څه دي چې د شبکې پالیسي کې جوړ شوي دي:

  • سیاستوال د چاپیریال لخوا محدود دي؛
  • پالیسي په لیبلونو نښه شوي پوډونو باندې پلي کیږي؛
  • قواعد په پوډونو، چاپیریالونو یا فرعي سایټونو کې پلي کیدی شي؛
  • قواعد کولی شي پروتوکولونه ولري، نومول شوي یا سمبولیک بندر مشخصات.

دلته دا دی چې کیلیکو دا دندې څنګه پراخوي:

  • پالیسۍ په هر شی کې پلي کیدی شي: پوډ، کانټینر، مجازی ماشین یا انٹرفیس؛
  • قواعد کولی شي یو ځانګړی عمل ولري (ممنوعیت، اجازه، ننوتل)؛
  • د مقرراتو هدف یا سرچینه کیدای شي یو بندر وي، د بندرونو لړۍ، پروتوکولونه، HTTP یا ICMP ځانګړتیاوې، IP یا subnet (4th یا 6th نسل)، هر انتخاب کونکي (نوډونه، کوربه، چاپیریال)؛
  • برسیره پردې، تاسو کولی شئ د DNAT ترتیباتو او د ټرافیک لیږلو پالیسیو په کارولو سره د ټرافیک تیریدل تنظیم کړئ.

د کالیکو په ذخیره کې د GitHub په اړه لومړی ژمنې د جولای 2016 ته نیټې پورې اړه لري، او یو کال وروسته پروژې د کوبرنیټس شبکې ارتباط تنظیم کولو کې مخکښ دریځ ترلاسه کړ - دا د بیلګې په توګه، د سروې پایلو لخوا ثابت شوی، د نوي سټیک لخوا ترسره شوی:

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

د K8s سره ډیری لوی مدیریت شوي حلونه، لکه ایمیزون EKS, Azure AKS, ګوګل GKE او نورو یې د کارولو لپاره سپارښتنه پیل کړه.

د فعالیت لپاره، دلته هرڅه عالي دي. د دوی د محصول په ازمایښت کې، د کالیکو پراختیایی ټیم د ستورپوهنې فعالیت وښوده، په 50000 کانټینرونو کې په 500 فزیکي نوډونو کې په هر ثانیه کې د 20 کانټینرونو د جوړولو کچه سره چلول. په اندازه کولو کې کومه ستونزه نده پیژندل شوې. داسې پایلې اعلان شول لا دمخه د لومړۍ نسخې په اعلان کې. خپلواکې مطالعې چې د زیرمو او سرچینو مصرف باندې تمرکز کوي دا هم تاییدوي چې د کالیکو فعالیت نږدې د فلانیل په څیر ښه دی. د مثال په توګه:

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

پروژه خورا ګړندۍ وده کوي ، دا د K8s ، OpenShift ، OpenStack اداره شوي مشهور حلونو کې د کار ملاتړ کوي ، دا ممکنه ده چې د کلستر په کارولو سره د کلستر ځای په ځای کولو کې د کالیکو وکاروئ کوپسد خدماتو میش شبکې جوړولو ته اشاره شتون لري (دلته یو مثال دی د اسټیو سره په ګډه کارول کیږي).

د کالیکو سره تمرین وکړئ

د وینیلا کوبرنیټس کارولو عمومي قضیه کې، د CNI نصب کول د فایل کارولو لپاره راځي calico.yaml, د رسمي ویب پاڼې څخه ډاونلوډ شوی، په کارولو kubectl apply -f.

د یوې قاعدې په توګه، د پلگ ان اوسنی نسخه د Kubernetes وروستي 2-3 نسخو سره مطابقت لري: په زړو نسخو کې عملیات ندي ازمول شوي او تضمین ندي. د پراختیا کونکو په وینا ، کیلیکو د 3.10 څخه پورته د لینکس کرنلونو چلوي CentOS 7 ، اوبنټو 16 یا Debian 8 ، د iptables یا IPVS په سر کې.

په چاپیریال کې جلا کول

د عمومي پوهاوي لپاره، راځئ چې یو ساده قضیه وګورو ترڅو پوه شي چې څنګه د کالیکو نوټیشن کې د شبکې پالیسۍ له معیاري څخه توپیر لري او څنګه د قواعدو رامینځته کولو طریقه د دوی د لوستلو وړتیا او ترتیب کولو انعطاف آسانوي:

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

په کلستر کې 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 څخه د ریډیس بندر ته راتلونکي ترافیک ته اجازه ورکړه. او دوی په ښکاره ډول بل څه منع نه کړل. هرڅومره ژر چې د شبکې پالیسي څرګندیږي ، ټول انتخاب کونکي په دې کې ذکر شوي جلا کول پیل کوي ، پرته لدې چې بل ډول مشخص شي. په هرصورت، د جلا کولو قواعد په نورو شیانو باندې نه پلي کیږي چې د انتخاب کونکي لخوا پوښل شوي ندي.

مثال یې کاروي 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، د یوې قاعدې په توګه، په جلا خدمت چاپیریال کې ځای پرځای شوی - په مثال کې دا به د نوم ځای وي:

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

په عموم کې، د ځانګړو اړتیاو لپاره د دې ډول پالیسیو په اضافه کولو سره، تاسو کولی شئ په کلستر کې د غوښتنلیکونو په عملیاتو کې د ناوړه یا ناڅاپي مداخلې په وړاندې ساتنه وکړئ.

د کالیکو د جوړونکو په وینا ترټولو غوره عمل د "هر څه بند کړئ او په ښکاره ډول هغه څه چې تاسو ورته اړتیا لرئ خلاص کړئ" طریقه ده چې مستند شوي رسمي اسناد (نور ورته ورته چلند تعقیبوي - په ځانګړي توګه په مخکې ذکر شوی مقاله).

د اضافي کالیکو شیانو کارول

اجازه راکړئ تاسو ته یادونه وکړم چې د کالیکو APIs پراخه سیټ له لارې تاسو کولی شئ د نوډونو شتون تنظیم کړئ ، نه په پوډونو پورې محدود. په لاندې مثال کې کارول GlobalNetworkPolicy په کلستر کې د ICMP غوښتنو د انتقال وړتیا تړل شوې ده (د مثال په توګه، د پوډ څخه نوډ ته پینګ کول، د پوډونو ترمنځ، یا د نوډ څخه IP پوډ ته):

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 قضیه

په نهایت کې ، زه به د نږدې کلستر تعامل قضیې لپاره د کالیکو افعال کارولو خورا ریښتیني مثال ورکړم ، کله چې د پالیسیو معیاري سیټ کافي نه وي. ویب غوښتنلیک ته د لاسرسي لپاره، پیرودونکي د VPN تونل کاروي، او دا لاسرسی په کلکه کنټرول شوی او د کارولو لپاره اجازه ورکړل شوي خدماتو ځانګړي لیست پورې محدود دی:

کالیکو په کوبرنیټس کې د شبکې لپاره: پیژندنه او لږ تجربه

پیرودونکي د معیاري UDP پورټ 1194 له لارې VPN سره وصل کیږي او کله چې وصل شي ، د پوډونو او خدماتو کلستر فرعي نیټونو ته لارې ترلاسه کوي. ټول فرعي نیټونه فشار راوړل شوي ترڅو د ادرسونو د بیا پیلولو او بدلولو پرمهال خدمات له لاسه ورنکړي.

په ترتیب کې بندر معیاري دی، کوم چې د غوښتنلیک ترتیبولو او د کوبرنیټس کلستر ته لیږدولو پروسې کې ځینې لنډیزونه وضع کوي. د مثال په توګه، د UDP لپاره په ورته AWS LoadBalancer کې د تیر کال په پای کې په لفظي توګه د سیمو محدود لیست کې څرګند شو، او نوډ پورټ نشي کارول کیدی ځکه چې په ټولو کلستر نوډونو کې د هغې د لیږلو له امله او د سرور مثالونو شمیر اندازه کول ناممکن دي. د خطا زغم اهداف برسیره پردې، تاسو باید د بندرونو ډیفالټ حد بدل کړئ ...

د ممکنه حلونو د لټون په پایله کې، لاندې غوره شوي:

  1. د VPN سره پوډونه په هر نوډ کې ټاکل شوي hostNetwork، دا دی، اصلي IP ته.
  2. خدمت له لارې بهر ځړول کیږي ClusterIP. یو بندر په فزیکي توګه په نوډ کې نصب شوی، کوم چې د وړو ریزرویشنونو سره د بهر څخه د لاسرسي وړ دی (د اصلي IP پتې مشروط شتون).
  3. د نوډ ټاکل چې په کوم کې د پوډ ګلاب زموږ د کیسې له ساحې بهر دی. زه به یوازې ووایم چې تاسو کولی شئ یو نوډ ته خدمت په کلکه "نیل" کړئ یا یو کوچني سایډ کار خدمت ولیکئ چې د VPN خدمت اوسنی IP پته به وڅاري او د پیرودونکو سره ثبت شوي DNS ریکارډونه ایډیټ کړي - څوک چې کافي تصور لري.

د روټینګ لید څخه ، موږ کولی شو د VPN پیرودونکي په ځانګړي ډول د VPN سرور لخوا صادر شوي IP پتې لخوا وپیژنو. لاندې خدماتو ته د ورته پیرودونکي لاسرسي محدودولو لومړنۍ بیلګه ده ، په پورته ذکر شوي ریډیس کې ښودل شوي:

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 خدمت عملیات ساتل کیږي ، چې فعالیت یې ډیری وختونه د قواعدو رامینځته کولو سره مخ کیږي. ځکه، لکه څنګه چې مخکې یادونه وشوه، کله چې یو انتخاب کونکی ښکاره شي، د ډیفالټ انکار پالیسي په هغې باندې پلي کیږي پرته لدې چې بل ډول مشخص شي.

پایلې

په دې توګه، د کالیکو پرمختللی API په کارولو سره، تاسو کولی شئ په انعطاف وړ توګه تنظیم او په متحرک ډول د کلستر دننه او شاوخوا روټینګ بدل کړئ. په عموم کې، د دې کارول کیدای شي د توپ سره د مرغیو د ډزو په څیر ښکاري، او د BGP او IP-IP تونلونو سره د L3 شبکې پلي کول په فلیټ شبکه کې د ساده Kubernetes نصبولو کې ډارونکي ښکاري ... په هرصورت، که نه نو دا وسیله خورا ګټور او ګټور ښکاري. .

د امنیت اړتیاو پوره کولو لپاره د کلستر جلا کول ممکن تل ممکن نه وي، او دا هغه ځای دی چې کیلیکو (یا ورته حل) د ژغورنې لپاره راځي. په دې مقاله کې ورکړل شوي مثالونه (د لږو تعدیلاتو سره) په AWS کې زموږ د پیرودونکو په څو تاسیساتو کې کارول کیږي.

PS

زموږ په بلاګ کې هم ولولئ:

سرچینه: www.habr.com

Add a comment