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

نن چهارشنبه، place will و.... د Kubernetes راتلونکی خپرونه - 1.16. د هغه دود له مخې چې زموږ د بلاګ لپاره رامینځته شوی، دا د لسمې کلیزې وخت دی چې موږ په نوې نسخه کې د خورا مهم بدلونونو په اړه خبرې کوو.

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

نوډونه

د ریښتیني لوی شمیر د پام وړ نوښتونه (د الفا نسخه حالت کې) د K8s کلستر نوډونو (کوبلیټ) په څنګ کې وړاندې کیږي.

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

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

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

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

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

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

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

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

سربیره پردې ، د RuntimeClass لپاره پرمختګ سمدلاسه د بیټا حالت کې شتون لري ، د "متضاد کلسترونو" لپاره ملاتړ اضافه کوي. ج د RuntimeClass مهالویش اوس دا د هر نوډ لپاره اړین ندي چې د هر RuntimeClass لپاره ملاتړ ولري: د پوډونو لپاره تاسو کولی شئ د کلسټر ټوپیولوژي په اړه فکر کولو پرته د RuntimeClass غوره کړئ. مخکې، د دې ترلاسه کولو لپاره - نو دا چې پوډونه د هر هغه څه لپاره چې دوی ورته اړتیا لري د ملاتړ سره په نوډونو کې پای ته رسیږي - دا اړینه وه چې د نوډ سلیکٹر او زغم ته مناسب قواعد وټاکئ. IN 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 - EndpointSlice API. دا د موجوده پای ټکی API د فعالیت / توزیع کولو مسلې حل کوي کوم چې په کنټرول-پلان کې مختلف اجزاو اغیزه کوي (apiserver, etcd, endpoints-controller, kube-proxy). نوی API به د کشف API ګروپ کې اضافه شي او د دې وړتیا ولري چې په هر خدمت کې د زرګونو نوډونو څخه په یوه کلستر کې د لسګونو زره بیک انډ پای پایټونو خدمت وکړي. د دې کولو لپاره، هر خدمت د N شیانو سره نقشه شوی EndpointSlice، چې هر یو یې د ډیفالټ له مخې له 100 څخه ډیر پای ټکي نلري (ارزښت د ترتیب وړ دی). د EndpointSlice API به د دې راتلونکي پرمختګ لپاره فرصتونه هم چمتو کړي: د هر پوډ لپاره د ډیری IP پتې ملاتړ ، د پای ټکي لپاره نوي ایالتونه (نه یوازې Ready и NotReady)، د پای ټکی لپاره متحرک فرعي ترتیب.

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

د API ماشین

د "ثبات مرحلې ریښتیني" د Kubernetes API سرور په ساحه کې دی او د هغې سره تعامل. دا په لویه کچه د مننه باثباته حالت ته د هغو کسانو لیږد چې ځانګړي معرفي ته اړتیا نلري د CustomResource تعریفونه (CRD)، کوم چې د کبرنیټس 1.7 لرې ورځو راهیسې د بیټا حالت لري (او دا د جون 2017 دی!). ورته ثبات د اړوندو ځانګړتیاو لپاره راغلی:

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

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

دوه نور ځانګړتیاوې بیټا ته رسیدلي: د سرور اړخ پلي کول и بک مارکونه وګورئ.

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

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

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

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

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

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

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

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

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

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

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

نور بدلونونه

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

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

د وینډوز پراختیا ملاتړ کوي с بڼه د دې OS (الفا نسخه) لپاره د Kubeadm اسانتیاوې، فرصت RunAsUserName د وینډوز کانټینرونو لپاره (الفا نسخه) ښه والی د ګروپ مدیریت شوي خدماتو حساب (gMSA) تر بیټا نسخه پورې ملاتړ کوي ملاتړ د vSphere حجمونو لپاره mount/altach.
رانیول شوی د API ځوابونو کې د ډیټا کمپریشن میکانیزم. پخوا، د دې موخو لپاره د HTTP فلټر کارول کیده، کوم چې یو شمیر محدودیتونه وضع کړل چې دا یې د ډیفالټ لخوا فعال کیدو مخه ونیوله. "شفاف غوښتنه کمپریشن" اوس کار کوي: پیرودونکي لیږل Accept-Encoding: gzip په سرلیک کې، دوی د GZIP-compressed ځواب ترلاسه کوي که چیرې د هغې اندازه د 128 KB څخه زیاته وي. پیرودونکي په اتوماتيک ډول د کمپریشن ملاتړ کوي (د اړتیا وړ سرلیک لیږل)، نو دوی به سمدلاسه په ترافیک کې کمښت وګوري. (د نورو ژبو لپاره لږ بدلون ته اړتیا لیدل کیدی شي.)
شونې شوه د خارجي میټریکونو پراساس د HPA څخه / صفر پوډونو ته اندازه کول. که تاسو د شیانو / بهرني میټریکونو پراساس اندازه کړئ ، نو کله چې د کار بارونه بې کاره وي تاسو کولی شئ په اتوماتيک ډول د سرچینو خوندي کولو لپاره 0 نقلونو ته اندازه کړئ. دا فیچر باید په ځانګړې توګه د هغو قضیو لپاره ګټور وي چیرې چې کارګران د GPU سرچینو غوښتنه کوي، او د بې کاره کارګرانو مختلف ډولونه د شته GPUs شمیر څخه ډیر دي.
نوی پیرودونکی - k8s.io/client-go/metadata.Client - شیانو ته د "عمومي" لاسرسي لپاره. دا د دې لپاره ډیزاین شوی چې په اسانۍ سره میټاډاټا ترلاسه کړي (د بیلګې په توګه فرعي برخه metadata) د کلستر سرچینو څخه او د دوی سره د کثافاتو راټولول او د کوټې عملیات ترسره کول.
Kubernetes جوړ کړئ اوس تاسو کولی شئ د میراث پرته (د ونې په دننه کې جوړ شوی) بادل چمتو کونکي (الفا نسخه).
د 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.
Kubeadm اوس خپلواک دی مهاجرت کوي د 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: د اصلي نوښتونو عمومي کتنه