د کبرنیټس کلستر کې د سوراخونو حل کول. د DevOpsConf څخه راپور او لیږد

Pavel Selivanov، د ساوت برج د حلونو معمار او د سلرم ښوونکي، په DevOpsConf 2019 کې یو پریزنټیشن وړاندې کړ. دا خبرې د Kubernetes "Slurm Mega" په اړه د ژورې کورس یوه برخه ده.

سلرم اساسی: د کوبرنیټس پیژندنه په مسکو کې د نومبر په 18-20 ترسره کیږي.
سلرم میګا: د کوبرنیټس د هود لاندې کتل - مسکو، د نومبر 22-24.
سلرم آنلاین: د کوبرنیټس دواړه کورسونه تل شتون لري.

د کټ لاندې د راپور نقل دی.

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

زه ګورم چې نن په تالار کې ډیری امنیتي ساتونکي دي. زه مخکې له تاسو څخه بخښنه غواړم که چیرې زه د امنیت نړۍ څخه اصطلاحات وکاروم لکه څنګه چې ستاسو لپاره دودیز ندي.

دا داسې پیښ شوي چې شاوخوا شپږ میاشتې دمخه ما د عامه Kubernetes کلستر سره ولیدل. عامه مطلب دا دی چې د نوم ځایونو نهم نمبر شتون لري؛ پدې نوم ځایونو کې کارونکي د دوی په نوم ځای کې جلا شوي دي. دا ټول کاروونکي په مختلفو شرکتونو پورې اړه لري. ښه، داسې انګیرل کیده چې دا کلستر باید د CDN په توګه وکارول شي. دا دی، دوی تاسو ته یو کلستر درکوي، دوی تاسو ته هلته یو کاروونکي درکوي، تاسو هلته خپل نوم ځای ته ځئ، خپل محاذونه ځای پر ځای کړئ.

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

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

دا داسې پیښ شول چې په دوه دقیقو کې ما د دوی کلستر ته یو اډمین ترلاسه کړ، د ګاونډیو ټولو نومونو ځایونو ته یې وکتل، هلته یې د شرکتونو چلونکي تولیدي محاذونه ولیدل چې دمخه یې خدمت اخیستی او ګمارل شوي. ما په سختۍ سره د یو چا مخ ته د تلو او په اصلي پا pageه کې د قسم کولو کلمه ایښودلو څخه ځان منع کولی.

زه به تاسو ته د مثالونو سره ووایم چې ما دا څنګه وکړل او څنګه له دې څخه ځان وژغورم.

مګر لومړی اجازه راکړئ خپل ځان معرفي کړم. زما نوم پاول سیلیوانوف دی. زه په جنوبي برج کې معمار یم. زه Kubernetes، DevOps او هر ډول په زړه پوري شیان پوهیږم. د سویل برج انجنیران او زه دا ټول جوړوم، او زه مشوره کوم.

زموږ د اصلي فعالیتونو سربیره، موږ په دې وروستیو کې د Slumms په نوم پروژې پیل کړې. موږ هڅه کوو چې د Kubernetes سره د کار کولو وړتیا یو څه خلکو ته راوړو، ترڅو نورو خلکو ته هم د K8s سره کار کولو زده کړو.

زه به نن د څه په اړه خبرې وکړم؟ د راپور موضوع روښانه ده - د Kubernetes کلستر امنیت په اړه. مګر زه غواړم سمدلاسه ووایم چې دا موضوع خورا لویه ده - او له همدې امله زه غواړم سمدلاسه روښانه کړم چې زه به د هغه څه په اړه خبرې ونه کړم. زه به د هیکني شرایطو په اړه خبرې ونه کړم چې دمخه په انټرنیټ کې سل ځله کارول شوي. هر ډول RBAC او سندونه.

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

دلته په لفظي توګه درې ټکي شتون لري چې زه به یې نن خبرې وکړم:

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

یو بل عمومي شی چې زه به یې یادونه وکړم هغه څه دي چې ما دا ټول ازمول ، په کوم کې چې زه واقعیا کولی شم ووایم چې دا ټول کار کوي.

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

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

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

kubectl apply -f pod.yaml

دا پوډ به د Kubernetes کلستر یو ماسټر ته ورسیږي. او له دې وروسته به کلستر په خوښۍ سره موږ ته د admin.conf په نوم فایل راوباسي. په کیوب کې، دا فایل ټول د مدیر سندونه ذخیره کوي، او په ورته وخت کې د کلستر API ترتیبوي. دا د اډمین لاسرسي ترلاسه کول څومره اسانه دي ، زما په اند ، د کوبرنیټس کلسترونو 98٪.

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

او اوس د ځانګړي چمتو شوي پوډ په اړه. موږ دا په هر عکس کې چلوو. راځئ debian: jessie د مثال په توګه واخلو.

موږ دا شیان لرو:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

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

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

د دې دوو برخو سره به خامخا بادار ته راځي. او هغه ته به هلته د اوسېدو اجازه ورکړل شي.

مګر یوازې ماسټر ته راتلل زموږ لپاره کافي ندي. دا به موږ ته هیڅ نه راکوي. نو بیا موږ دا دوه شیان لرو:

hostNetwork: true 
hostPID: true 

موږ مشخص کوو چې زموږ پوډ چې موږ یې پیل کوو، د کرنل نوم ځای کې، د شبکې نوم ځای کې، او د PID نوم ځای کې ژوند کوي. یوځل چې پوډ په ماسټر کې پیل شي ، نو دا به د دې وړتیا ولري چې د دې نوډ ټول ریښتیني ، ژوندی انٹرفیسونه وګوري ، ټول ترافیک واورئ او د ټولو پروسو PID وګورئ.

بیا د کوچنیو شیانو خبره ده. etcd واخلئ او هغه څه ولولئ چې تاسو یې غواړئ.

ترټولو په زړه پورې شی د دې Kubernetes ځانګړتیا ده، کوم چې د ډیفالټ لخوا شتون لري.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

او د دې جوهر دا دی چې موږ کولی شو په پوډ کې ووایو چې موږ لانچ کوو ، حتی د دې کلستر له حقونو پرته ، چې موږ غواړو د hostPath ډول حجم رامینځته کړو. دا پدې مانا ده چې د کوربه څخه لاره واخلئ په کوم کې چې موږ به یې پیل کړو - او د حجم په توګه یې واخلو. او بیا موږ ورته نوم ورکوو: کوربه. موږ دا ټول کوربه پاټ د پوډ دننه نصب کوو. په دې مثال کې، / کوربه ډایرکټر ته.

زه به یې بیا تکرار کړم. موږ پوډ ته وویل چې ماسټر ته راشئ ، هلته hostNetwork او hostPID ترلاسه کړئ - او د دې پوډ دننه د ماسټر ټوله ریښه نصب کړئ.

تاسو پوهیږئ چې په ډیبیان کې موږ باش چلولی شو ، او دا باش د ریښې لاندې تیریږي. دا دی، موږ یوازې په ماسټر کې روټ ترلاسه کړ، پرته له دې چې د کوبرنیټس کلستر کې کوم حقونه ولري.

بیا ټوله دنده دا ده چې فرعي ډایرکټر ته لاړ شئ /host /etc/kubernetes/pki، که زه غلط نه یم، هلته د کلستر ټول ماسټر سندونه واخلئ او په وینا یې د کلستر مدیر شئ.

که تاسو دا په دې ډول وګورئ، دا په پوډونو کې ځینې خورا خطرناک حقونه دي - پرته له دې چې کاروونکي کوم حقونه لري:

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

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

د کوربه لارې حجم، زما په اند، د Kubernetes کلستر څخه د مطلوب پایلې ترلاسه کولو ترټولو ګړندۍ لاره ده.

مګر د دې ټولو سره څه وکړي؟

هغه فکر چې باید هر عادي مدیر ته راشي چې د کوبرنیټس سره مخ کیږي دا دی: "هو ، ما تاسو ته وویل ، کوبرنیټس کار نه کوي. په هغه کې سوراخ شتون لري. او ټول مکعب غل دی.» په حقیقت کې، د اسنادو په څیر یو شی شتون لري، او که تاسو هلته وګورئ، یوه برخه شتون لري د پوډ امنیت پالیسي.

دا یو yaml څیز دی - موږ کولی شو دا د Kubernetes کلستر کې رامینځته کړو - کوم چې امنیت اړخونه په ځانګړي ډول د پوډونو په توضیح کې کنټرولوي. دا په حقیقت کې، دا د هر ډول hostNetwork، hostPID، د ځینې حجم ډولونو کارولو حقونه کنټرولوي چې په پیل کې په پوډونو کې دي. د پوډ امنیتي پالیسۍ په مرسته، دا ټول تشریح کیدی شي.

د پوډ امنیت پالیسۍ په اړه خورا په زړه پوري شی دا دی چې د کوبرنیټس کلستر کې ټول PSP نصب کونکي یوازې په هیڅ ډول ندي بیان شوي ، دوی په ساده ډول د ډیفالټ لخوا غیر فعال شوي. د پوډ امنیت پالیسي د داخلې پلگ ان په کارولو سره فعاله شوې.

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

او هرڅه زموږ سره سم ښکاري. او زموږ د کوبرنیټس کلستر په دوه دقیقو کې هیک نشي کیدی.

یوه ستونزه ده. ډیری احتمال، که تاسو د Kubernetes کلستر لرئ، نو بیا څارنه ستاسو په کلستر کې نصب شوې. زه به حتی تر هغه حده لاړ شم چې وړاندوینه وکړم که ستاسو کلستر نظارت ولري ، نو دا به د پرومیتیس په نوم یاد شي.

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

شاید هرڅوک په هابری کې ورته مقالې ولولي، او څارنه د څارنې نوم ځای کې موقعیت لري. د هیلم چارټ تقریبا د هرچا لپاره ورته ویل کیږي. زه اټکل کوم چې که تاسو د سټیبل/پرومیتیوس هیلم نصب کړئ، نو تاسو به د نږدې ورته نومونو سره پای ته ورسیږئ. او ډیری احتمال زه به حتی ستاسو په کلستر کې د DNS نوم اټکل ونه کړم. ځکه چې دا معیاري ده.

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

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics د Prometheus صادرونکو څخه یو دی چې پخپله د Kubernetes API څخه میټریک راټولوي. دلته ډیر معلومات شتون لري، ستاسو په کلستر کې څه روان دي، دا څه دي، تاسو ورسره کومې ستونزې لرئ.

د ساده مثال په توګه:

kube_pod_container_info{namespace="kube-system",pod="kube-apisserver-k8s- 1″,container="kube-apisserver",image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

د یو غیر مستحق پوډ څخه د ساده curl غوښتنې په کولو سره ، تاسو کولی شئ لاندې معلومات ترلاسه کړئ. که تاسو نه پوهیږئ د کوبرنیټس کومه نسخه تاسو پرمخ وړئ ، دا به تاسو ته په اسانۍ سره ووایی.

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

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

لکه څنګه چې د PSP سره، داسې احساس کوي چې ستونزه دا ده چې دا ټول فینسي ټیکنالوژي - Kubernetes، Prometheus - دوی یوازې کار نه کوي او له سوریو ډک دي. واقعیآ نه.

داسې یو شی شتون لري - د شبکې پالیسي.

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

حتی که تاسو خپلو امنیتي متخصصینو ته نه وای ویلي چې ستاسو د کوبرنیټس په کارولو سره تاسو کولی شئ خورا اسانه او ساده فایروال جوړ کړئ ، او په دې کې خورا ګران. که دوی تر اوسه پدې نه پوهیږي او تاسو نه ځوروي: "ښه، ماته راکړه، ماته راکړه ..." بیا په هر حالت کې، تاسو د شبکې پالیسۍ ته اړتیا لرئ ترڅو ځینې خدماتو ځایونو ته لاسرسی بند کړئ چې ستاسو له کلستر څخه ایستل کیدی شي. پرته له کومې اجازې.

لکه څنګه چې په مثال کې ما ورکړ، تاسو کولی شئ د کوبرنیټس کلستر کې د هر نوم ځای څخه د کیوب ریاست میټریکونه پورته کړئ پرته له دې چې د دې کولو حق ولري. د شبکې پالیسیو د نورو ټولو نوم ځایونو څخه د څارنې نوم ځای ته لاسرسی بند کړی دی او دا دی: هیڅ لاسرسی نشته ، هیڅ ستونزه نشته. په ټولو چارټونو کې چې شتون لري، دواړه معیاري Prometheus او Prometheus چې په آپریټر کې دي، د هیلم ارزښتونو کې په ساده ډول د دوی لپاره د شبکې پالیسۍ فعالولو لپاره یو اختیار شتون لري. تاسو یوازې دې ته اړتیا لرئ او دوی به کار وکړي.

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

زه باید څه وکړم؟

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

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

کله چې تاسو یو نوی کلستر پورته کړئ، په ورته وخت کې د فلالین پر ځای کیلیکو داخل کړئ.

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

یوه ستونزه شته. پخوا، دا د کوبی-RBAC-پراکسي حل د آپریټر پرومیتیس کې جوړ شوی و. مګر بیا هغه لاړ. اوس عصري نسخې په دې حقیقت تکیه کوي چې تاسو د شبکې پالیسي لرئ او د دوی په کارولو سره یې وتړئ. او له همدې امله موږ باید چارټ یو څه بیا ولیکو. په حقیقت کې، که تاسو لاړ شئ دا ذخیره، دلته مثالونه شتون لري چې دا څنګه د سایډ کار په توګه وکاروئ ، او چارټونه باید لږترلږه بیا لیکل شي.

یوه بله کوچنۍ ستونزه ده. پرومیتیوس یوازینی کس نه دی چې خپل میټریکونه یوازې هرچا ته ورکوي. زموږ د Kubernetes ټول کلستر برخې هم د دې وړتیا لري چې خپل میټریک بیرته راستانه کړي.

مګر لکه څنګه چې ما مخکې وویل، که تاسو نشئ کولی کلستر ته لاسرسی ومومئ او معلومات راټول کړئ، نو تاسو لږترلږه یو څه زیان رسولی شئ.

نو زه به ژر تر ژره دوه لارې وښیم چې څنګه د کبرنیټس کلستر ویجاړ کیدی شي.

تاسو به وخندل کله چې زه تاسو ته دا ووایم، دا د ریښتینې ژوند دوه قضیې دي.

یوه طریقه. د سرچینو کمښت.

راځئ چې یو بل ځانګړی پوډ پیل کړو. دا به د دې په څیر یوه برخه ولري.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

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

که زه دا ډول پوډ چلوم ، نو زه به کمانډ پرمخ وړم:

$ kubectl scale special-pod --replicas=...

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

که موږ د کبرنیټس اسنادو ته بیا وګورو ، نو موږ به دا شی وګورو چې د حد حد په نوم یادیږي. دا د کلستر شیانو لپاره سرچینې ټاکي. تاسو کولی شئ په yaml کې د محدودیت رینج اعتراض ولیکئ، دا په ځانګړو نوم ځایونو کې پلي کړئ - او بیا پدې نوم ځای کې تاسو کولی شئ ووایاست چې تاسو د پوډونو لپاره ډیفالټ، اعظمي او لږترلږه سرچینې لرئ.

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

او دا هغه ځای دی چې د دوهم نمبر میتود څخه راځي. موږ د 11 پوډونه پیل کوو. دا یوولس ملیارد دی. دا د دې لپاره نه دی چې زه د داسې شمیر سره راغلی یم، مګر دا چې ما پخپله ولیدل.

ریښتینې کیسه. ماښام ناوخته له دفتره د وتلو په حال کې وم. زه د پراختیا کونکو یوه ډله ګورم چې په کونج کې ناست دي ، په لیپټاپونو کې په لیپټاپ سره یو څه کوي. زه هلکانو ته لاړم او پوښتنه یې وکړه: "تاسو څه شوي؟"

لږ مخکې، د ماښام شاوخوا نهه بجې، یو پرمخ وړونکی کور ته د تګ لپاره چمتو و. او ما پریکړه وکړه: "زه اوس زما غوښتنلیک یو ته راکم کړم." ما یو فشار ورکړ، مګر انټرنیټ یو څه ورو شو. هغه یو ځل بیا فشار ورکړ، هغه یې فشار ورکړ، او په Enter کلیک وکړئ. ما هر څه چې زه یې کولی شم وخورلم. بیا انټرنیټ ژوند ته راغی - او هر څه دې شمیرې ته راټیټیدل پیل کړل.

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

په طبیعي توګه، ما هڅه وکړه چې په کبرنیټس کې ورته کار وکړم. کوبرنیټس د یوولس ملیارد پوډونو څخه خوښ نه و ، هغه وویل: "زه نشم کولی. د داخلي خولې ساتونکو څخه ډیر دی." مګر 1 پوډونه کولی شي.

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

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

مګر ما پریکړه وکړه چې نور هم لاړ شم. لکه څنګه چې تاسو پوهیږئ، په Kubernetes کې داسې شی شتون لري چې د خدمت په نوم یادیږي. ښه، ستاسو په کلسترونو کې د ډیفالټ په واسطه، ډیری احتمال، خدمت د IP جدولونو په کارولو سره کار کوي.

که تاسو یو ملیارد پوډونه چلوئ، د بیلګې په توګه، او بیا یو سکریپټ وکاروئ ترڅو Kubernetis مجبور کړي چې نوي خدمات رامینځته کړي:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

د کلستر په ټولو نوډونو کې، ډیر او ډیر نوي iptables قواعد به نږدې په ورته وخت کې رامینځته شي. سربیره پردې ، د هر خدمت لپاره به یو ملیارد iptables قواعد رامینځته شي.

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

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

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

د سرچینو کوټه + د حد حد + RBAC
• د نوم ځای جوړ کړئ
• دننه یو محدودیت جوړ کړئ
• د منابعو دننه کوټه جوړه کړئ
• د CI لپاره د خدماتو حساب جوړ کړئ
• د CI او کاروونکو لپاره د رول پابند کول
• په اختیاري توګه د اړین خدماتو پوډونه پیل کړئ

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

په لومړي سر کې دا په ځواب کې لیکل شوی و، او بیا ما ولیدل چې د SDK آپریټر شتون درلود او د ځواب وړ رول یې په آپریټر کې بیا لیکلی و. دا بیان تاسو ته اجازه درکوي د کوبرنیټس کلستر کې یو څیز رامینځته کړئ چې د کمانډ په نوم یادیږي. د کمانډ دننه، دا تاسو ته اجازه درکوي چې په یامل کې د دې قوماندې لپاره چاپیریال تشریح کړئ. او د ټیم چاپیریال کې، دا موږ ته اجازه راکوي چې تشریح کړو چې موږ ډیری سرچینې تخصیص کوو.

لږ دا ټوله پیچلې پروسه اسانه کول.

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

د شبکې پالیسي یوازې یو بل غیر ضروري ځانګړتیا نه ده. دا هغه څه دي چې واقعیا په کلستر کې ورته اړتیا لري.

LimitRange/ResourceQuota - دا د کارولو وخت دی. موږ دا ډیر وخت دمخه کارول پیل کړل، او د اوږدې مودې لپاره زه ډاډه وم چې هرڅوک یې کاروي. دا معلومه شوه چې دا نادره ده.

د هغه څه سربیره چې ما د راپور په جریان کې یادونه وکړه، غیر مستند شوي ځانګړتیاوې شتون لري چې تاسو ته اجازه درکوي په کلستر برید وکړئ. په دې وروستیو کې خپور شو د Kubernetes زیانمننې پراخه تحلیل.

ځینې ​​شیان ډیر غمجن او دردونکي دي. د مثال په توګه، د ځانګړو شرایطو لاندې، د Kubernetes کلستر کې کیوبلیټونه کولی شي د وارلاک ډایرکټر مینځپانګه یو غیر مجاز کارونکي ته ورکړي.

ټوټ دلته لارښوونې شتون لري چې څنګه هرڅه چې ما تاسو ته وویل بیا تولید کړئ. د تولید مثالونو سره فایلونه شتون لري چې د ریسورس کوټا او پوډ امنیت پالیسي څنګه ښکاري. او تاسو کولی شئ دا ټول لمس کړئ.

د ټولو څخه مننه.

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