په کبرنیټس کې د لومړي غوښتنلیک ځای په ځای کولو کې پنځه یادونه

د ایریس ډریمر لخوا ناکام شو

ډیری خلک فکر کوي چې دا کافي دی چې کوبرنیټس ته غوښتنلیک انتقال کړئ (یا د هیلم یا په لاسي ډول کارول) - او خوښي به وي. مګر هرڅه دومره ساده ندي.

ټیم Mail.ru کلاوډ حلونه د DevOps انجینر جولین ګیندي لخوا یوه مقاله ژباړل شوې. هغه وايي چې د مهاجرت پروسې په جریان کې د هغه شرکت کوم زیانونه سره مخ شوي ترڅو تاسو په ورته ریک باندې ګام ونه کړئ.

لومړی ګام: د پوډ غوښتنې او محدودیتونه تنظیم کړئ

راځئ چې د پاک چاپیریال په جوړولو سره پیل وکړو چیرې چې زموږ پوډونه به وځي. کوبرنیټس د پوډ مهالویش او ناکامۍ کې عالي دی. مګر دا معلومه شوه چې مهالویش کونکی کله ناکله نشي کولی پوډ ځای په ځای کړي که چیرې دا اټکل کول ستونزمن وي چې دا په بریالیتوب سره کار کولو لپاره څومره سرچینو ته اړتیا لري. دا هغه ځای دی چې د سرچینو او محدودیتونو غوښتنه کوي. د غوښتنو او حدودو ترتیب کولو لپاره د غوره طریقې په اړه ډیر بحث شتون لري. ځینې ​​​​وختونه داسې ښکاري چې دا واقعیا د ساینس په پرتله یو هنر دی. دلته زموږ چلند دی.

د پوډ غوښتنې اصلي ارزښت دی چې د مهالویش کونکي لخوا کارول کیږي ترڅو پوډ په غوره توګه ځای په ځای کړي.

له د Kubernetes اسناد: د فلټر مرحله د نوډونو سیټ تعریفوي چیرې چې پوډ ټاکل کیدی شي. د مثال په توګه، د PodFitsResources فلټر چک کوي ترڅو وګوري چې ایا نوډ د پوډ څخه د ځانګړو سرچینو غوښتنې پوره کولو لپاره کافي سرچینې لري.

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

پدې حالت کې ، مهالویش کونکی به ډیری وختونه پوډونه "چوچ کړي" او نشي کولی د دوی له سره مهالویش وکړي ځکه چې د کنټرول الوتکه نه پوهیږي چې غوښتنلیک به څومره سرچینو ته اړتیا ولري ، کوم چې د مهالویش الګوریتم کلیدي برخه ده.

د پوډ محدودیتونه د پوډ لپاره روښانه حد دی. دا د سرچینو اعظمي مقدار استازیتوب کوي چې کلستر به کانټینر ته تخصیص کړي.

یو ځل بیا، څخه رسمي اسناد: که یو کانټینر د حافظې حد 4 GiB ولري، نو کیوبیلټ (او د کانټینر چلولو وخت) به دا پلي کړي. د چلولو وخت کانټینر د ټاکل شوي سرچینې حد څخه ډیر کارولو مخه نیسي. د مثال په توګه، کله چې په کانټینر کې یوه پروسه هڅه کوي د یاد شوي مقدار څخه ډیر کار واخلي، د سیسټم کارنل پروسه د "یاد څخه بهر" (OOM) غلطی سره پای ته رسوي.

یو کانټینر تل کولی شي د سرچینې غوښتنې مشخص کولو څخه ډیرې سرچینې وکاروي ، مګر دا هیڅکله نشي کولی له حد څخه ډیر وکاروي. دا ارزښت په سمه توګه ټاکل ستونزمن دی، مګر دا خورا مهم دی.

په عین حال کې، موږ غواړو د پوډ سرچینې اړتیاوې د پروسې د ژوند دورې په جریان کې بدل شي پرته له دې چې په سیسټم کې د نورو پروسو سره مداخله وکړي - دا د محدودیتونو ټاکلو هدف دی.

له بده مرغه، زه نشم کولی د کوم ارزښتونو ټاکلو په اړه ځانګړي لارښوونې ورکړم، مګر موږ پخپله لاندې مقرراتو ته غاړه ایښودو:

1. د بار ازموینې وسیلې په کارولو سره ، موږ د ټرافیک اساس کچه انډول کوو او د پوډ سرچینو (میموري او پروسیسر) کارول مشاهده کوو.
2. د پوډ غوښتنې په خپل سري ډول ټیټ ارزښت ته تنظیم کړئ (د سرچینو حد سره د غوښتنې ارزښت شاوخوا 5 ځله) او مشاهده کړئ. کله چې غوښتنې په خورا ټیټه کچه وي ، نو پروسه نشي پیل کیدی ، کوم چې ډیری وختونه د کریپټیک Go چلولو غلطیو لامل کیږي.

زه یادونه کوم چې د سرچینو لوړ محدودیتونه مهالویش ډیر ستونزمن کوي ​​ځکه چې پوډ د کافي سرچینو سره د هدف نوډ ته اړتیا لري.

د داسې وضعیت تصور وکړئ چیرې چې تاسو د خورا لوړ سرچینې محدودیت سره لږ وزن لرونکي ویب سرور لرئ ، لکه د 4 GB حافظه. دا پروسه به احتمالا په افقی ډول اندازه کولو ته اړتیا ولري ، او هر نوی پوډ به اړتیا ولري چې لږترلږه 4 GB موجود حافظې سره په نوډ کې تنظیم شي. که چیرې داسې نوډ شتون ونلري، کلستر باید د دې پوډ پروسس کولو لپاره یو نوی نوډ معرفي کړي، کوم چې ممکن یو څه وخت ونیسي. دا مهمه ده چې د سرچینو غوښتنې او محدودیتونو ترمنځ لږترلږه توپیر ترلاسه کړئ ترڅو د چټک او اسانه پیمانه ډاډ ترلاسه شي.

دوهم ګام: د ژوندانه او چمتووالي ازموینې تنظیم کړئ

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

ژوندون ښیي که کانټینر روان وي. که دا ناکام شي، کیبلټ کانټینر وژني او د بیا پیل کولو پالیسي د دې لپاره فعاله شوې. که کانټینر د Liveness Probe سره مجهز نه وي، نو اصلي حالت به بریالی وي - لکه څنګه چې ویل شوي د Kubernetes اسناد.

د ژوندانه تحقیقات باید ارزانه وي، د بیلګې په توګه ډیرې سرچینې نه مصرفوي، ځکه چې دوی په مکرر ډول چلیږي او باید Kubernetes ته خبر ورکړي چې غوښتنلیک روان دی.

که تاسو د هرې ثانیې چلولو اختیار وټاکئ، نو دا به په هره ثانیه کې 1 غوښتنه اضافه کړي، نو په دې پوه شئ چې اضافي سرچینې به د دې ټرافیک پروسس کولو ته اړتیا ولري.

زموږ په شرکت کې، Liveness ازموینې د غوښتنلیک اصلي برخې ازموینه کوي، حتی که ډاټا (د مثال په توګه، د لیرې ډیټابیس یا کیچ څخه) په بشپړه توګه شتون نلري.

موږ په غوښتنلیکونو کې د "روغتیا" پای ټکی رامینځته کړی چې په ساده ډول د 200 ځواب کوډ بیرته راګرځوي. دا یوه نښه ده چې پروسه روانه ده او د غوښتنو اداره کولو وړتیا لري (مګر تر اوسه ترافیک ندي).

نمونه چمتووالی دا په ګوته کوي چې آیا کانټینر د غوښتنو خدمت کولو لپاره چمتو دی. که د چمتووالي تحقیقات ناکام شي، د پای ټکی کنټرولر د پوډ IP پته د پوډ سره سمون لرونکي ټولو خدماتو پای ټکي څخه لرې کوي. دا د Kubernetes په اسنادو کې هم ویل شوي.

د چمتووالي تحقیقات ډیرې سرچینې مصرفوي، ځکه چې دوی باید شاته په داسې ډول ودریږي چې دا وښيي چې غوښتنلیک د غوښتنو منلو ته چمتو دی.

په ټولنه کې ډیر بحثونه شتون لري چې ایا ډیټابیس ته مستقیم لاسرسی ومومئ. د سر په پام کې نیولو سره (چیکونه مکرر دي ، مګر دوی کنټرول کیدی شي) ، موږ پریکړه وکړه چې د ځینې غوښتنلیکونو لپاره ، د ترافیک خدمت کولو چمتووالی یوازې د چیک کولو وروسته شمیرل کیږي چې ریکارډونه د ډیټابیس څخه بیرته راستانه شوي. د ښه ډیزاین شوي چمتووالي آزموینې د شتون لوړه کچه تضمین کړه او د ګمارنې پرمهال د ځنډ وخت له مینځه وړل.

که تاسو پریکړه وکړئ چې د خپل غوښتنلیک چمتووالي ازموینې لپاره ډیټابیس پوښتنه وکړئ ، ډاډ ترلاسه کړئ چې دا د امکان تر حده ارزانه ده. راځئ چې دا پوښتنه واخلو:

SELECT small_item FROM table LIMIT 1

دلته یو مثال دی چې څنګه موږ دا دوه ارزښتونه په کوبرنیټس کې تنظیم کوو:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

تاسو کولی شئ د ترتیب کولو ځینې اضافي اختیارونه اضافه کړئ:

• initialDelaySeconds - څو ثانیې به د کانټینر لانچ او د پروبونو د پیل کولو تر مینځ تیریږي.
• periodSeconds - د نمونې منډو تر مینځ د انتظار وقفه.
• timeoutSeconds - د ثانیو شمیر چې وروسته پوډ بیړني حالت ګڼل کیږي. نورمال وخت پای.
• failureThreshold پوډ ته د بیا پیل سیګنال لیږلو دمخه د ازموینې ناکامیو شمیر دی.
• successThreshold چمتو حالت ته د پوډ لیږد دمخه د بریالۍ ازموینو شمیر دی (د ناکامۍ وروسته کله چې پوډ پیل شي یا روغ شي).

دریم ګام: د پوډ ډیفالټ شبکې پالیسۍ تنظیم کول

Kubernetes د "فلایټ" شبکې توپوګرافي لري، د ډیفالټ په واسطه ټول پوډونه مستقیم له یو بل سره اړیکه لري. په ځینو مواردو کې دا د منلو وړ نه ده.

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

د مثال په توګه، لاندې یو ساده پالیسي ده چې د یو ځانګړي نوم ځای لپاره ټول راتلونکی ټرافیک ردوي:

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

د دې ترتیب لید:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
نور جزئيات دلته.

څلورم ګام: د هکس او انټ کانټینرونو سره دودیز چلند

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

سره ځانګړې ستونزې رامنځته شوې نګینکس. موږ ولیدل چې کله دا پوډونه په ترتیب سره ځای په ځای کول، فعال ارتباطات په بریالیتوب سره بشپړولو دمخه مداخله شوې.

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

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

خو nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

بل خورا ګټور تمثیل د ځانګړي غوښتنلیکونو پیل کولو اداره کولو لپاره د init کانټینرونو کارول دي. دا په ځانګړې توګه ګټور دی که تاسو د سرچینې ژور ډیټابیس مهاجرت پروسه لرئ چې باید د غوښتنلیک پیل کیدو دمخه پرمخ وړل شي. تاسو کولی شئ د دې پروسې لپاره د سرچینې لوړ حد هم مشخص کړئ پرته لدې چې د اصلي غوښتنلیک لپاره دا ډول حد ترتیب کړئ.

بل عام سکیم د init کانټینر کې رازونو ته لاسرسی دی ، کوم چې اصلي ماډل ته دا اسناد چمتو کوي ، کوم چې پخپله د اصلي غوښتنلیک ماډل څخه رازونو ته د غیر مجاز لاسرسي مخه نیسي.

د معمول په څیر، د اسنادو څخه اقتباس: init کانټینرونه په خوندي ډول د کارونکي کوډ یا اسانتیاوې پرمخ وړي چې بل ډول به د غوښتنلیک کانټینر عکس امنیت سره موافقت وکړي. د غیر ضروري وسیلو جلا ساتلو سره ، تاسو د غوښتنلیک کانټینر عکس برید سطح محدود کړئ.

پنځم ګام: د کرنل ترتیب

په نهایت کې ، راځئ چې د یو پرمختللي تخنیک په اړه وغږیږو.

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

په هرصورت، Kubernetes تاسو ته اجازه درکوي یو امتیاز لرونکی کانټینر چل کړئ چې یوازې د ځانګړي پوډ لپاره د کرنل پیرامیټونه بدلوي. دلته هغه څه دي چې موږ یې د خلاص اړیکو اعظمي شمیر بدلولو لپاره کارولي:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

په پای کې

پداسې حال کې چې کوبرنیټس ممکن د بکس څخه بهر د حل په څیر ښکاري ، دلته یو څو کلیدي ګامونه شتون لري چې باید د غوښتنلیکونو په سمه توګه پرمخ وړلو لپاره ونیول شي.

Kubernetes ته د مهاجرت په جریان کې، دا مهمه ده چې د "لوډ ټیسټ دوره" تعقیب کړئ: غوښتنلیک چل کړئ، دا د بار لاندې ازموینه وکړئ، د میټریک او اندازه کولو چلند وګورئ، د دې معلوماتو پراساس ترتیب تنظیم کړئ، بیا دا دوره بیا تکرار کړئ.

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

تل له ځانه دا پوښتنې وکړئ:

1. غوښتنلیکونه څومره سرچینې مصرفوي او دا مقدار به څنګه بدل شي؟
2. د اندازه کولو اصلي اړتیاوې څه دي؟ ایپ به په اوسط ډول څومره ترافیک اداره کړي؟ د لوړ ترافیک په اړه څه؟
3. څومره وخت به خدمت اندازه کولو ته اړتیا ولري؟ د ټرافیک ترلاسه کولو لپاره نوي پوډونه څومره ژر پورته کیدو او چلولو ته اړتیا لري؟
4. پوزې څومره په زړه پورې تړل کیږي؟ ایا دا بالکل اړین دی؟ ایا دا ممکنه ده چې پرته له ځنډ څخه ګمارل ترلاسه کړئ؟
5. څنګه کولی شو امنیتي خطرونه کم کړو او د هر ډول جوړ شوي پوډ څخه زیان محدود کړو؟ ایا کوم خدمتونه اجازه یا لاسرسی لري چې دوی ورته اړتیا نلري؟

Kubernetes یو نه منلو وړ پلیټ فارم چمتو کوي چې تاسو ته اجازه درکوي په کلستر کې د زرګونو خدماتو ځای پرځای کولو لپاره غوره تمرینونه وکاروئ. په هرصورت، ټول غوښتنلیکونه توپیر لري. ځینې ​​​​وختونه پلي کول لږ کار ته اړتیا لري.

خوشبختانه، Kubernetes د ټولو تخنیکي اهدافو ترلاسه کولو لپاره اړین ترتیبات چمتو کوي. د منابعو د غوښتنو او محدودیتونو د ترکیب په کارولو سره، د ژوندانه او چمتووالي تحقیقات، د انټ کانټینرونو، د شبکې پالیسي، او د ګمرک کرنل ټونینګ، تاسو کولی شئ د غلطۍ زغم او ګړندي توزیع کولو سره لوړ فعالیت ترلاسه کړئ.

نور څه ولولئ:

1. د تولید چاپیریال کې د کانټینرونو او کبرنیټ چلولو لپاره غوره تمرینونه او غوره کړنې.
2. د کبرنیټس لپاره 90+ ګټورې وسیلې: ځای په ځای کول، مدیریت، څارنه، امنیت او نور ډیر څه.
3. زموږ چینل په ټیلیګرام کې د کوبرنیټس شاوخوا.

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