🥇Kubernetes 1.16: د اصلي نوښتونو عمومي کتنه

نن، چهارشنبه، place will و.... د کوبرنیټس وروستۍ خپرونه ۱.۱۶ ده. زموږ د بلاګ د دود سره سم، د لسم ځل لپاره، موږ په نوي نسخه کې خورا مهم بدلونونه روښانه کوو.

د دې موادو د چمتو کولو لپاره کارول شوي معلومات له دې څخه اخیستل شوي د Kubernetes د پرمختګ تعقیب میزونه, بدلون-1.16 او اړونده مسلې، د پل غوښتنې، او د کوبرنیټس د لوړولو وړاندیزونه (KEPs). نو، راځئ چې پیل وکړو!

نوډونه

د K8s کلستر نوډونو (Kubelet) په اړخ کې د پام وړ نوښتونو (په الفا حالت کې) واقعیا لوی شمیر وړاندې کیږي.

لومړی، تش په نامه «لنډمهاله کانتینرونه» (لنډمهاله کانتینرونه)، په پوډونو کې د ډیبګ کولو پروسې ساده کولو لپاره ډیزاین شوینوی میکانیزم د ځانګړو کانټینرونو د پیلولو اجازه ورکوي چې د موجوده پوډونو په نوم ځای کې پیل کیږي او د لنډ وخت لپاره ژوند کوي. د دوی هدف د ستونزو حل کولو او ډیبګ کولو موخو لپاره د نورو پوډونو او کانټینرونو سره تعامل کول دي. د دې ځانګړتیا لپاره یو نوی قومانده پلي شوې ده. kubectl debug، په اصل کې ورته kubectl exec: یوازې د دې پرځای چې پروسه په کانټینر کې پرمخ بوځي (لکه څنګه چې په قضیه کې exec) دا په یوه پوډ کې یو کانټینر پیل کوي. د مثال په توګه، دا قومانده به یو نوی کانټینر په یوه پوډ سره وصل کړي:

kubectl debug -c debug-shell --image=debian target-pod -- bash

د لنډمهاله کانتینرونو په اړه توضیحات (او د دوی د کارولو مثالونه) په کې موندل کیدی شي اړونده KEPاوسنی تطبیق (په K8s 1.16 کې) د الفا نسخه ده، او د بیټا ته د لیږدولو لپاره یو له معیارونو څخه "د لږترلږه 2 [کوبرنیټس] ریلیزونو لپاره د ایفیمیرل کانټینرونو API ازموینه کول دي."

NB: په خپل اصل او حتی نوم کې، دا ځانګړتیا د موجوده پلگ ان سره ورته ده kubectl-debugد کوم په اړه چې موږ دمخه یې لیکليتمه کیږي چې د لنډمهاله کانټینرونو په راتګ سره، د جلا بهرني پلګ ان پراختیا به ودریږي.

یو بل نوښت دا دی - PodOverhead — د چمتو کولو لپاره دی د پوډ سر د محاسبې میکانیزم، کوم چې د کارول شوي رن ټایم چاپیریال پورې اړه لري خورا توپیر کولی شي. د مثال په توګه، لیکوالان دا KEP د کاټا کانټینرونه، چې د میلمه کرنل، کاټا اجنټ، یو init سیسټم، او داسې نورو چلولو ته اړتیا لري، کارول کیږي. کله چې سر دومره لوی شي، نو دا له پامه غورځول کیدی نشي، پدې معنی چې د راتلونکي کوټو، مهالویش، او نورو لپاره د حساب ورکولو لپاره یوه لاره اړینه ده. د دې پلي کولو لپاره PodSpec ساحه اضافه شوه Overhead *ResourceList (د معلوماتو سره پرتله کول په RuntimeClass، که کارول کیږي).

یو بل د پام وړ نوښت دا دی د نوډ ټوپولوژي مدیر (د نوډ ټوپولوژي مدیر)، د کوبرنیټس کې د مختلفو برخو لپاره د هارډویر سرچینو تخصیص د ښه تنظیم کولو لپاره د طریقې یووالي لپاره ډیزاین شوی. دا نوښت د لوړ فعالیت موازي کمپیوټري او د عملیاتو اجرا کولو پرمهال د لږترلږه ځنډ لپاره د مختلفو عصري سیسټمونو (د مخابراتو، ماشین زده کړې، مالي خدماتو، او نورو برخو کې) د مخ په زیاتیدونکي اړتیا لخوا پرمخ وړل کیږي، د کوم لپاره چې دوی پرمختللي CPU او هارډویر سرعت وړتیاوې کاروي. په کوبرنیټس کې دا ډول اصلاحونه دمخه د متفاوت اجزاو (CPU مدیر، د وسیلې مدیر، CNI) له لارې ترلاسه شوي. اوس به دوی ته یو متحد داخلي انٹرفیس ورکړل شي، کوم چې طریقه سره یوځای کوي او د کوبرنیټس اړخ کې د نوي ورته - تش په نامه ټوپولوژي - پوهاوي - اجزاو اړیکه ساده کوي. توضیحات په کې دي اړونده KEP.

د ټوپولوژي مدیر اجزا ډیاګرام

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

سربېره پردې، د بیټا حالت کې د رن ټایم کلاس لپاره یو ښه والی معرفي شو، چې د "متفاوت کلسترونو" لپاره ملاتړ یې اضافه کړ. C د رنټیم کلاس مهالویش اوس، هر نوډ د هر RuntimeClass ملاتړ ته اړتیا نلري: تاسو کولی شئ د کلستر ټوپولوژي په اړه اندیښنې پرته د خپلو پوډونو لپاره RuntimeClass غوره کړئ. مخکې، د دې ترلاسه کولو لپاره - د دې ډاډ ترلاسه کولو لپاره چې پوډونه په نوډونو کې ځای په ځای شوي چې هرڅه چې دوی ورته اړتیا لري ملاتړ کوي - تاسو باید د NodeSelector او زغم لپاره مناسب قواعد وټاکئ. CAP دا د کارونې مثالونو او البته د پلي کولو توضیحاتو په اړه وايي.

شبکه

د شبکې دوه مهمې ځانګړتیاوې چې د لومړي ځل لپاره (په الفا کې) په Kubernetes 1.16 کې راڅرګندې شوې دي:

ملاتړ دوه ګونی شبکې سټک - IPv4/IPv6 — او د هغې اړونده "پوهاوی" په پوډ، نوډ، او خدماتو کچه کې. پدې کې د پوډونو ترمنځ IPv4-to-IPv4 او IPv6-to-IPv6 تعاملات شامل دي، د پوډونو څخه تر بهرني خدماتو پورې، د حوالې پلي کول (د برج CNI، PTP CNI، او کوربه-ځایي IPAM پلگ انونو دننه)، او همدارنګه د Kubernetes کلسترونو سره شاته مطابقت چې یوازې د IPv4 یا IPv6 څخه تیریږي. د پلي کولو توضیحات په کې دي. CAP.
په پوډ لیست کې د دوه ډوله IP پتو (IPv4 او IPv6) ښودلو یوه بیلګه:
```
kube-master# kubectl get pods -o wide
NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
kube-master#
```
د پای ټکی لپاره نوی API - د پای ټکی سلائس APIدا د موجوده Endpoint API د فعالیت او د پیمانه کولو مسلو ته رسیدګي کوي، کوم چې د کنټرول الوتکې کې مختلف اجزا اغیزمن کوي (apiserver، etcd، endpoints-controller، kube-proxy). نوی API به د Discovery API ګروپ ته اضافه شي او د زرګونو نوډونو څخه جوړ شوي کلستر کې به په هر خدمت کې د لسګونو زرو بیک انډ پای نقطو خدمت کولو توان ولري. د دې ترلاسه کولو لپاره، هر خدمت د N شیانو سره نقشه شوی. EndpointSlice، چې هر یو یې د 100 پای ټکو ډیفالټ حد لري (ارزښت یې د تنظیم وړ دی). د EndpointSlice API به د راتلونکي پراختیا لپاره فرصتونه هم چمتو کړي: د هر پوډ لپاره د ډیری IP پتې ملاتړ، د پای ټکو لپاره نوي حالتونه (نه یوازې Ready и NotReady)، د پای ټکو لپاره متحرک فرعي ترتیب.

هغه ځانګړتیا چې په تیرو نسخو کې معرفي شوې وه بیټا ته رسیدلې ده نهايي کوونکینومول شوی service.kubernetes.io/load-balancer-cleanup او د هر خدمت سره د ډول سره وصل دی LoadBalancerکله چې دا ډول خدمت حذف شي، نو دا د سرچینې اصلي حذف کیدو مخه نیسي تر هغه چې ټولې اړونده متوازن سرچینې پاکې نشي.

د API ماشینري

د Kubernetes API سرور او ورسره د تعامل په برخه کې د "ثبات یو ریښتینی پړاو" ته رسیدلی دی. دا په لویه کچه د دې له امله و باثباته حالت ته لیږدول ځانګړي معرفي ته اړتیا نلري د ګمرک سرچینې تعریفونه (سي آر ډي)، کوم چې د کوبرنیټس ۱.۷ له لرې ورځو راهیسې په بیټا حالت کې و (دا د ۲۰۱۷ کال جون وه!). اړوند ځانګړتیاوې هم ثبات لري:

فرعي سرچینې سره /status и /scale د ګمرکي سرچینو لپاره؛
اړول د CRD لپاره نسخې، د بهرني ویب هک پر بنسټ؛
په دې وروستیو کې وړاندې شوی (په K8s 1.15 کې) ډیفالټ ارزښتونه (ډیفالټ) او د ساحو اتوماتیک لرې کول (برخه کول) د ګمرکي سرچینو لپاره؛
فرصت د OpenAPI v3 سکیما کارول ترڅو د OpenAPI اسناد جوړ او خپاره کړي چې د سرور اړخ CRD سرچینو تایید لپاره کارول کیږي.

یو بل میکانیزم چې د کوبرنیټ مدیرانو سره له ډیرې مودې راهیسې بلد شوی دی: د داخلې ویب هک — د اوږدې مودې لپاره په بیټا حالت کې هم پاتې شو (د K8s 1.9 راهیسې) او اوس مستحکم اعلان شوی.

دوه نور ځانګړتیاوې بیټا ته رسیدلي دي: د سرور-سایډ تطبیق и د لید بک مارکونه.

او په الفا نسخه کې یوازینی د پام وړ نوښت و ناکامي от SelfLink — یو ځانګړی URI چې د ټاکل شوي شی استازیتوب کوي او د هغې برخه ده ObjectMeta и ListMeta (یعنې، په کوبرنیټس کې د هر شی یوه برخه). ولې پریښودل کیږي؟ هڅونه "ساده" ده. غږونه د دې ساحې د دوام لپاره د ریښتیني (مجبور) دلیل نشتوالی. نور رسمي دلیلونه د فعالیت غوره کول دي (د غیر ضروري ساحې لرې کولو سره) او د عمومي-اپیسرور کار ساده کول دي، کوم چې اړ دی چې دا ډول ساحه په ځانګړي ډول اداره کړي (دا یوازینۍ ساحه ده چې د یو شی د سریال کولو دمخه سم تنظیم شوې ده). ریښتینی "تخریب" (د بیټا نسخه دننه) SelfLink د Kubernetes نسخې ۱.۲۰ لخوا به ترسره شي، او وروستۍ به یې په ۱.۲۱ کې ترسره شي.

د معلوماتو ذخیره

د ذخیره کولو په ساحه کې اصلي کار، لکه څنګه چې په تیرو خپرونو کې، په سیمه کې لیدل کیږي د CSI ملاتړدلته اصلي بدلونونه دا وو:

د لومړي ځل لپاره (په الفا نسخه کې) ښکاره شوه د وینډوز کارګر نوډونو لپاره د CSI پلگ ان ملاتړ: د ذخیره کولو سره د کار کولو یوه اوسنۍ لاره او دلته به دا د کوبرنیټس کور کې د ونې دننه پلگ انونه او د پاورشیل پر بنسټ د مایکروسافټ څخه د فلیکس والیوم پلگ انونه ځای په ځای کړي؛

د وینډوز لپاره په Kubernetes کې د CSI پلگ انونو د پلي کولو ډیاګرام
فرصت د CSI حجمونو اندازه کول، چې په K8s 1.12 کې معرفي شوی، بیټا نسخه ته رسیدلی دی؛
ورته "اپ گریڈ" (له الفا څخه بیټا ته) د CSI کارولو وړتیا کې ترلاسه شو ترڅو سیمه ایز لنډمهاله حجمونه رامینځته کړي (د CSI انلاین حجم ملاتړ).

د کوبرنیټس په پخوانۍ نسخه کې معرفي شوی د حجم کلونینګ فعالیت (د موجوده PVC په کارولو سره لکه څنګه چې DataSource د نوي PVCs جوړولو لپاره) اوس د بیټا نسخې حالت هم ترلاسه کړی دی.

مهالویش کوونکی

په پلان جوړونه کې دوه د پام وړ بدلونونه (دواړه په الفا کې):

EvenPodsSpreading - فرصت د بارونو "عادلانه ویش" لپاره د منطقي غوښتنلیک واحدونو پرځای پوډونه وکاروئ (لکه ډیپلایمینټ او ریپلیکا سیټ) او د دې ویش تنظیم کول (د سخت اړتیا یا نرم حالت په توګه، د بیلګې په توګه، لومړیتوب). دا ځانګړتیا به د مهالویش شوي پوډونو لپاره د موجوده ویش اختیارونه پراخ کړي، چې اوس مهال محدود دي PodAffinity и PodAntiAffinity، مدیرانو ته پدې مسله کې ډیر دقیق کنټرول ورکوي، چې پدې معنی ده چې غوره لوړ شتون او مطلوب سرچینې مصرف. توضیحات په کې دي CAP.
کارول د غوره فټ پالیسي в د غوښتنې سره سم د ظرفیت تناسب لومړیتوب فعالیت د پوډ مهالویش په جریان کې، کوم چې به اجازه ورکړي کارول د ډبو بسته بندي ("په کانټینرونو کې بسته بندي کول") د اصلي سرچینو (پروسیسر، حافظې) او پراخو سرچینو (لکه GPU) لپاره. د نورو جزیاتو لپاره، وګورئ CAP.

د پوډ مهالویش: د غوره فټ پالیسۍ کارولو دمخه (مستقیم د ډیفالټ مهالویش کونکي له لارې) او د هغې سره (د مهالویش کونکي توسیع کونکي له لارې)

سربیره پردې، استازیتوب د د اصلي Kubernetes پراختیایي ونې (د ونې څخه بهر) څخه بهر د خپل مهالویش کونکي پلگ انونو جوړولو وړتیا.

نور بدلونونه

د Kubernetes 1.16 په خپریدو کې هم د یادونې وړ ده نوښت ته راوړل موجوده میټریکونه په بشپړ ترتیب کې، یا په ډیر دقیق ډول، د دې سره سم رسمي مقررات د K8s وسایلو ته. دوی په لویه کچه په اړونده تکیه کوي د پرومیتیس اسنادناانډولۍ د مختلفو دلایلو له امله رامینځته شوې (د مثال په توګه، ځینې میټریکونه په ساده ډول د اوسني لارښوونو له خپریدو دمخه رامینځته شوي وو)، او پراختیا کونکو پریکړه وکړه چې دا د هرڅه معیاري کولو وخت دی، "د پرومیټیوس ایکوسیستم د پاتې برخې سره سم." د دې نوښت اوسنی پلي کول په الفا حالت کې دي، کوم چې به په تدریجي ډول د کوبرنیټس په راتلونکو خپرونو کې بیټا (1.17) او مستحکم (1.18) ته لوړ شي.

سربیره پردې، لاندې بدلونونه لیدل کیدی شي:

د وینډوز ملاتړ وده کوي с بڼه د دې عملیاتي سیسټم لپاره د Kubeadm اسانتیاوې (الفا نسخه)، فرصت RunAsUserName د وینډوز کانټینرونو لپاره (الفا نسخه)، ښه والی د ګروپ مدیریت شوي خدماتو حساب (gMSA) ملاتړ بیټا ته، ملاتړ د vSphere حجمونو لپاره نصب/ضمیمه کول.
بیا کارول شوی د API ځوابونو کې د معلوماتو د کمپریشن میکانیزمپخوا، د دې موخو لپاره د HTTP فلټر کارول کیده، کوم چې یو شمیر محدودیتونه وضع کړل چې دا یې د ډیفالټ لخوا فعالولو څخه منع کړ. اوس، "شفاف غوښتنې کمپریشن" په ځای کې دی: مراجعین لیږل Accept-Encoding: gzip په سرلیک کې، د GZIP-کمپریس شوی ځواب ترلاسه کړئ که چیرې د هغې اندازه له 128 KB څخه زیاته وي. د ګو مراجعین په اتوماتيک ډول د کمپریشن ملاتړ کوي (د اړین سرلیک لیږلو سره)، نو تاسو به سمدلاسه د ترافیک کمښت وګورئ. (د نورو ژبو لپاره ممکن کوچني بدلونونه اړین وي.)
دا ممکنه شوه د بهرني میټریکونو پراساس د HPA اندازه کول له صفر پوډونو څخه/تهکه چیرې اندازه کول د شیانو / بهرني میټریکونو پراساس وي، نو کله چې د کار بارونه بې کاره وي، نو دا ممکنه ده چې په اتوماتيک ډول د سرچینو د ساتلو لپاره 0 نقلونو ته راټیټ شي. دا ځانګړتیا باید په ځانګړي ډول په هغه قضیو کې ګټوره وي چیرې چې کارګران د GPU سرچینو غوښتنه کوي، او د بې کاره کارګرانو مختلف ډولونو شمیر د شته GPUs شمیر څخه ډیر وي.
نوی مراجع - k8s.io/client-go/metadata.Client — شیانو ته د "عمومي" لاسرسي لپاره. دا د میټاډاټا په اسانۍ سره ترلاسه کولو لپاره دی (د بیلګې په توګه فرعي برخه metadata) د کلستر سرچینو څخه راټول کړئ او د هغوی سره عملیات ترسره کړئ لکه د کثافاتو راټولول او د کوټې مدیریت.
کوبرنیټس جوړ کړئ اوس تاسو کولی شئ پرته له میراثي (په ونې کې) کلاوډ چمتو کونکي (الفا نسخه).
په kubeadm افادیت کې زیاته کړه د عملیاتو په جریان کې د دودیز پیچونو پلي کولو لپاره تجربوي (الفا) وړتیا init, join и upgradeد بیرغ کارولو څرنګوالي په اړه نور معلومات زده کړئ. --experimental-kustomize، وګورئ په CAP.
د اپیسرور لپاره نوی پای ټکی — readyz، کوم چې تاسو ته اجازه درکوي چې د هغې د چمتووالي په اړه معلومات صادر کړئ. د API سرور هم یو بیرغ لري --maximum-startup-sequence-duration، تاسو ته اجازه درکوي چې د هغې بیا پیل تنظیم کړئ.
دوه د Azure ځانګړتیاوې مستحکم اعلان شو: ملاتړ د شتون زونونه (د شتون زونونه) او د سرچینو متقابل ګروپ (RG) سربیره پردې، Azure اضافه کړې ده:
- د تصدیق ملاتړ AAD او ADFS؛
- لنډیز service.beta.kubernetes.io/azure-pip-name د بار بیلانسر عامه IP مشخص کول؛
- فرصت امستنې LoadBalancerName и LoadBalancerResourceGroup.
AWS یو نوی لري ملاتړ په وینډوز کې د EBS لپاره او غوره شوی د EC2 API زنګونه DescribeInstances.
کوبیدم اوس خپلواک دی مهاجرت کوي د CoreDNS نسخه د لوړولو پر مهال د CoreDNS ترتیب.
بائنري etcd په اړونده ډاکر انځور کې کړي دي د نړۍ اجرا وړ، کوم چې دا انځور ته اجازه ورکوي چې د روټ امتیازاتو اړتیا پرته چل شي. برسیره پردې، د etcd مهاجرت انځور ودرول د etcd2 نسخې ملاتړ.
В د کلستر آټوسکلر 1.16.0 موږ د ډیسټرولیس کارولو ته د اساس عکس په توګه مخه کړه، فعالیت مو ښه کړ، او نوي کلاوډ چمتو کونکي (ډیجیټل اوشن، میګنم، پیکټ) مو اضافه کړل.
په کارول شوي/تړلي سافټویر کې تازه معلومات: Go 1.12.9، etcd 3.3.15، CoreDNS 1.6.2.

PS

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

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

Kubernetes 1.16: د اصلي نوښتونو عمومي کتنه