🥇Kubernetes 1.17: مکيه جدت جو جائزو

ڪالهه، ڊسمبر 9، جڳه ورتي ڪبرنيٽس جو ايندڙ رليز - 1.17. روايت جي مطابق جيڪا اسان جي بلاگ لاء ترقي ڪئي آهي، اسان نئين ورزن ۾ سڀ کان اهم تبديلين بابت ڳالهايون ٿا.

هن مواد کي تيار ڪرڻ لاءِ استعمال ڪيل معلومات سرڪاري اعلان مان ورتي وئي آهي، Kubernetes واڌارو ٽريڪنگ ٽيبل, تبديلي-1.17 ۽ لاڳاپيل مسئلا، پل درخواستون، ۽ ڪبرنيٽس اينهانسمينٽ پروپوزل (KEP). پوء نئون ڇا آهي؟..

Topology-ڄاڻندڙ رستو

ڪبرنيٽس ڪميونٽي ڪافي عرصي کان هن فيچر جو انتظار ڪري رهي آهي - Topology-ڄاڻندڙ سروس روٽنگ. جيڪڏهن ڪيپ اهو آڪٽوبر 2018 ۾ پيدا ٿئي ٿو، ۽ سرڪاري واڌ - 2 سال اڳ، معمولي مسئلا (جهڙوڪ ان) - ۽ ڪجهه سال پراڻا...

عام خيال Kubernetes ۾ رهندڙ خدمتن لاء "مقامي" رستي تي عمل ڪرڻ جي صلاحيت مهيا ڪرڻ آهي. هن معاملي ۾ "مقامي" جو مطلب آهي "ساڳي سطحي سطح" (ٽپوولوجي سطح)، جيڪو ٿي سگهي ٿو:

خدمتن لاءِ هڪجهڙا نوڊ،
ساڳيو سرور ريڪ،
ساڳئي علائقي
ساڳيو بادل فراهم ڪندڙ،
...

ھن خصوصيت کي استعمال ڪرڻ جا مثال:

بادل تنصيب ۾ ٽرئفڪ تي بچت ڪيترن ئي دستيابي زونن سان (ملٽي-AZ) - ڏسو. تازو مثال ساڳئي علائقي مان ٽرئفڪ جو مثال استعمال ڪندي، پر AWS ۾ مختلف AZs؛
گھٽ ڪارڪردگي ويڪرائي / بهتر throughput؛
هڪ شارڊ ٿيل خدمت جيڪا هر شارڊ ۾ نوڊ بابت مقامي معلومات رکي ٿي؛
fluentd (يا analogues) جي جڳهه ساڳئي نوڊ تي ايپليڪيشنن سان گڏ جن جا لاگ گڏ ڪيا ويا آهن؛
...

اهڙي روٽنگ، جيڪا ٽوپولوجي جي باري ۾ ”ڄاڻ“ آهي، ان کي نيٽ ورڪ لاڳاپو پڻ چئبو آهي - قياس سان نوڊ لاڳاپو, پوڊ لاڳاپو / ضد وابستگي يا ظاهر ٿيو ايترو وقت اڳ نه Topology-Aware Volume Scheduling (۽ مقدار جي فراهمي). موجوده سطح تي عملدرآمد ServiceTopology Kubernetes ۾ - الفا ورزن.

تفصيل لاءِ ته خصوصيت ڪيئن ڪم ڪري ٿي ۽ توهان اڳ ۾ ئي ان کي ڪيئن استعمال ڪري سگهو ٿا، پڙهو اهو مضمون ليکڪن مان هڪ کان.

IPv4 / IPv6 ٻٽي اسٽيڪ سپورٽ

اهم ترقي مقرر ٻي نيٽ ورڪ خصوصيت ۾: هڪ ئي وقت ۾ ٻه IP اسٽيڪ لاءِ سپورٽ، جيڪو پهريون ڀيرو متعارف ڪرايو ويو هو K8s 1.16. خاص طور تي، نئين رليز ھيٺ ڏنل تبديليون آڻيا:

kube-proxy ۾ لاڳو ڪيو ويو ٻنهي طريقن ۾ هڪ ئي وقت آپريشن جو امڪان (IPv4 ۽ IPv6)؛
в Pod.Status.PodIPs ظاهر ٿيو هيٺيون API لاءِ سپورٽ (ساڳئي وقت ۾ جيئن /etc/hosts ھاڻي انھن کي ھوسٽ جي ضرورت آھي IPv6 ايڊريس شامل ڪرڻ لاءِ؛
ڊبل اسٽيڪ سپورٽ KIND (Kubernetes IN Docker) ۽ kubeadm;
تازه ڪاري e2e ٽيسٽ.

مثال ڏيڻ استعمال ڪندي ڊبل اسٽيڪ IPV4/IPv6 قسم ۾

CSI تي ترقي

مستحڪم قرار ڏنو topology جي حمايت CSI جي بنياد تي اسٽوريج لاء، پهريون ڀيرو متعارف ڪرايو ويو K8s 1.12.

لاء شروعات حجم پلگ ان جي منتقلي CSI ڏانهن - CSI لڏپلاڻ - بيٽا ورزن تائين پهچي ويو. موجوده اسٽوريج پلگ ان کي ترجمو ڪرڻ لاءِ هي خصوصيت اهم آهي (وڻ ۾) جديد انٽرفيس ڏانهن (CSI، وڻ کان ٻاهر) Kubernetes جي آخري استعمال ڪندڙن لاءِ پوشیدہ. ڪلسٽر منتظمين کي صرف CSI لڏپلاڻ کي فعال ڪرڻ جي ضرورت پوندي، جنهن کان پوءِ موجوده رياستي وسيلا ۽ ڪم لوڊ جاري رهندو ”صرف ڪم“... پر ڪبرنيٽس ڪور ۾ شامل ڪيل پراڻين بدران جديد CSI ڊرائيور استعمال ڪندي.

هن وقت، AWS EBS ڊرائيورن لاءِ لڏپلاڻ بيٽا ورزن ۾ تيار آهي (kubernetes.io/aws-ebs) ۽ GCE PD (kubernetes.io/gce-pd). ٻين اسٽوريج سهولتن لاءِ اڳڪٿيون هن ريت آهن:

اسان ڳالهايو ته ڪيئن "روايتي" اسٽوريج سپورٽ K8s ۾ CSI ۾ آئي اهو مضمون. ۽ بيٽا اسٽيٽس ڏانهن CSI لڏپلاڻ جي منتقلي لاء وقف آهي الڳ اشاعت پروجيڪٽ بلاگ تي.

ان کان علاوه، CSI جي حوالي سان هڪ ٻي اهم ڪارڪردگي، جيڪا K1.17s 8 ۾ (الفا عمل درآمد) پيدا ٿئي ٿي، بيٽا اسٽيٽس تائين پهچي وئي (يعني ڊفالٽ طور تي فعال) ڪبرنيٽس 1.12 رليز ۾ - تصوير ٺاهڻ ۽ انهن مان وصولي. بيٽا ڇڏڻ جي رستي تي ڪبرنيٽس حجم سنيپ شاٽ ۾ ڪيل تبديلين ۾:

CSI خارجي سنيپ شاٽر سائڊ ڪار کي ٻن ڪنٽرولرز ۾ ورهائڻ،
حذف ڪرڻ لاء راز شامل ڪيو ويو (خاطر راز) حجم سنيپ شاٽ جي مواد جي تشريح جي طور تي،
نئون فائنل ڪندڙ (فائنلائزر) سنيپ شاٽ API اعتراض کي ختم ٿيڻ کان روڪڻ لاءِ جيڪڏهن باقي ڪنيڪشن آهن.

رليز 1.17 جي وقت تي، خصوصيت کي ٽن CSI ڊرائيورن جي مدد ملي ٿي: GCE Persistent Disk CSI ڊرائيور، Portworx CSI ڊرائيور ۽ NetApp Trident CSI ڊرائيور. ان جي عمل ۽ استعمال جي باري ۾ وڌيڪ تفصيل ۾ ملي ڪري سگهجي ٿو هن اشاعت بلاگ تي.

ڪلائوڊ فراهم ڪندڙ ليبل

ليبل جيڪي خودڪار استعمال ٿيل ڪلائوڊ فراهم ڪندڙ جي بنياد تي ٺاهيل نوڊس ۽ حجمن کي لڳايو ويو آهي، ڪبرنيٽس ۾ بيٽا ورزن جي طور تي ڪافي عرصي تائين دستياب آھي - K8s 1.2 جي ڇڏڻ کان وٺي (اپريل 2016!). انهن جي وسيع استعمال کي ايتري عرصي تائين ڏني وئي، ڊولپرز فيصلو ڪيو، ته اهو وقت آهي اعلان ڪرڻ جو خصوصيت مستحڪم (GA).

تنهن ڪري، انهن سڀني جو نالو تبديل ڪيو ويو (ٽپوولوجي طرفان):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... پر اڃا تائين انهن جي پراڻي نالن هيٺ موجود آهن (پٺاڻ مطابقت لاء). جڏهن ته، سڀني منتظمين کي موجوده ليبلز تي سوئچ ڪرڻ جي صلاح ڏني وئي آهي. لاڳاپيل دستاويز K8s اپڊيٽ ڪيو ويو آهي.

kubeadm جو ٺهيل پيداوار

پهريون ڀيرو الفا ورزن ۾ پيش ڪيو ويو kubeadm افاديت لاء ٺهيل پيداوار. سپورٽ فارميٽ: JSON، YAML، Go ٽيمپليٽ.

ھن خصوصيت کي لاڳو ڪرڻ جي حوصلا افزائي (جي مطابق ڪيپ) آهي:

جڏهن ته ڪبرنيٽس کي دستي طور تي ترتيب ڏئي سگهجي ٿو، هن آپريشن لاءِ ڊي فيڪٽو (جيڪڏهن جوري نه هجي) معيار ڪبيڊم استعمال ڪرڻ آهي. مشهور سسٽم مئنيجمينٽ ٽولز جهڙوڪ Terraform ڪبرنيٽس جي تعیناتي لاءِ kubeadm تي ڀاڙين ٿا. ڪلستر API ۾ منصوبابندي ڪيل سڌارن ۾ Kubernetes بوٽ اسٽريپنگ لاءِ kubeadm ۽ cloud-init سان گڏ ٺهيل پيڪيج شامل آهن.

بغير منظم ٿيل پيداوار جي، پهرين نظر ۾ سڀ کان وڌيڪ معصوم تبديليون ٽرافارم، ڪلستر API ۽ ٻين سافٽ ويئر کي ٽوڙي سگهن ٿيون جيڪي kubeadm جا نتيجا استعمال ڪن ٿا.

اسان جي فوري منصوبن ۾ ھيٺ ڏنل ڪبيڊم حڪمن لاءِ مدد (منظم ٿيل ٻاھرين جي صورت ۾) شامل آھن:

alpha certs
config images list
init
token create
token list
upgrade plan
version

هڪ حڪم جي JSON جواب جو مثال kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

ٻين جدت جي استحڪام

عام طور تي، Kubernetes 1.17 جي رليز جي مقصد تحت ٿي ويو "استحڪام" اها حقيقت اها آهي ته ان ۾ ڪيتريون ئي خاصيتون (انهن جو ڪل تعداد آهي 14GA جي حيثيت حاصل ڪئي. انهن مان:

"مارڪينگ" نوڊس ڪجهه شرطن جي مطابق (TaintNodesByCondition) ۾ ظاهر ٿيو K8s 1.8;
بک مارڪ ڏسو - واقعن جو هڪ نئون قسم جنهن تي هڪ ليبل هجي ته سڀئي شيون هڪ خاص ورزن تائين آهن (resourceVersion) اڳ ۾ ئي واچ طرفان پروسيس ڪيو ويو آهي؛
ڊفالٽ قدر (ڊفالٽ) ڪسٽم وسيلن لاء؛
ڪنٽينرز جي وچ ۾ ورهايل پوڊ جي عمل جي نالي جي جڳھ ۾؛
ScheduleDaemonSetPods - DaemonSet ۾ شيڊولنگ پوڊ kube-scheduler استعمال ڪندي (DemonSet ڪنٽرولر جي بدران)؛
متحرڪ حدون نوڊ جي قسم تي منحصر مقدار جي تعداد تي؛
ماحولياتي variable حمايت ڊاريڪٽري جي نالن لاء جيئن نصب ٿيل subPath;
Kubelet دل جي ڌڙڪن جي منتقلي هڪ خاص ليز API ڏانهن؛
"فائنلائزر تحفظ" (حتمي تحفظ) لوڊ بيلنسرز لاءِ (LoadBlancer وسيلن کي ختم ڪرڻ کان پهريان لاڳاپيل خدمت وسيلن جي جانچ ڪندي)؛
kube-apiserver اصلاح ڪارڪردگي ۾ جڏهن ڪيترن ئي واچن سان ڪم ڪندي هڪجهڙائي وارين شين جي نگراني ڪندي - حاصل ڪيل هر ڏسندڙ لاءِ ساڳئي شين جي بار بار سيريلائيزيشن کان پاسو ڪندي.

Otherيون تبديليون

Kubernetes 1.17 ۾ جدت جي مڪمل فهرست، يقينا، مٿي ڏنل فهرستن تائين محدود ناهي. هتي ڪجھ ٻيا آھن (۽ وڌيڪ مڪمل فهرست لاء، ڏسو چانگگال):

آخري رليز ۾ پيش ڪيل خصوصيت بيٽا ورزن تائين پهچي چڪي آهي RunAsUserName ونڊوز لاءِ;
ساڳي تبديلي ٿيو EndpointSlice API (K8s 1.16 کان پڻ)، جڏهن ته هن وقت لاءِ هي حل بهتر ڪرڻ لاءِ Endpoint API جي ڪارڪردگي/Scalability کي ڊفالٽ طور فعال نه ڪيو ويو آهي؛
پوڊ هاڻي ڪلسٽر آپريشن لاءِ نازڪ آهن ٺاهي سگهجي ٿو نه رڳو نالي جي جڳهن ۾ kube-system (تفصيل لاءِ، ڏسو دستاويز لاءِ ترجيحي طبقي جي استعمال کي محدود ڪريو);
ڪوبيليٽ لاءِ نئون آپشن - --reserved-cpus - توهان کي سسٽم لاءِ مخصوص ڪيل CPUs جي فهرست کي واضح طور تي بيان ڪرڻ جي اجازت ڏئي ٿي؛
لاء kubectl logs پيش ڪيو نئون پرچم --prefix, لاگ جي هر قطار ۾ پوڊ ۽ ماخذ ڪنٽينر جو نالو شامل ڪرڻ؛
в label.Selector شامل ڪيو ويو RequiresExactMatch;
سڀ ڪنٽينر kube-dns ۾ هاڻي هلي رهيا آهن گهٽ امتياز سان؛
hyperkube الڳ GitHub مخزن ۾ ورهايو ويو ۽ هاڻي ڪوبرنيٽس رليز ۾ شامل نه ڪيو ويندو؛
گهڻو بهتر ڪارڪردگي kube-proxy غير UDP بندرگاهن لاءِ.

انحصار تبديليون:

kubeadm ۾ شامل CoreDNS نسخو 1.6.5 آهي؛
crictl ورجن کي اپڊيٽ ڪيو ويو v1.16.1؛
CSI 1.2.0؛
وغيره 3.4.3؛
جديد ٽيسٽ ٿيل ڊڪر ورزن 19.03 تائين اپ گريڊ ڪيو ويو؛
Kubernetes 1.17 ٺاهڻ لاءِ گھٽ ۾ گھٽ Go ورجن گھربل آھي 1.13.4.

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

Kubernetes 1.17: مکيه جدت جو جائزو