Kubernetes 1.17: نکات برجسته از آنچه جدید است

دیروز 9 دسامبر صورت گرفت نسخه بعدی Kubernetes - 1.17. طبق سنتی که برای وبلاگ ما ایجاد شده است، در مورد مهم ترین تغییرات در نسخه جدید صحبت می کنیم.

اطلاعات مورد استفاده برای تهیه این مطالب از اطلاعیه رسمی گرفته شده است. جداول ردیابی پیشرفت های Kubernetes, CHANGELOG-1.17 و مسائل مرتبط، درخواست‌های کشش، و پیشنهادهای ارتقای Kubernetes (KEP). خب، چه خبر؟..

مسیریابی آگاه از توپولوژی

جامعه Kubernetes برای مدت طولانی منتظر این ویژگی بوده است - مسیریابی سرویس آگاه از توپولوژی. اگر کلاه لبه دار در اکتبر 2018 سرچشمه می گیرد و رسمی تقویت - 2 سال پیش، مسائل معمول (پسندیدن آن) - و چند سال دیگر بزرگتر ...

ایده کلی این است که توانایی پیاده‌سازی مسیریابی «محلی» را برای سرویس‌های ساکن در Kubernetes فراهم کنیم. "محل" در این مورد به معنای "همان سطح توپولوژیکی" است. (سطح توپولوژی)، که ممکن است:

• گره یکسان برای خدمات،
• همان رک سرور،
• همان منطقه
• همان ارائه دهنده ابر،
• ...

نمونه هایی از استفاده از این ویژگی:

• صرفه جویی در ترافیک در تاسیسات ابری با چندین منطقه در دسترس (multi-AZ) - ببینید. تصویر تازه با استفاده از مثال ترافیک از همان منطقه، اما AZ های مختلف در AWS.
• تأخیر عملکرد کمتر / توان عملیاتی بهتر.
• یک سرویس خرد شده که دارای اطلاعات محلی در مورد گره در هر خرده است.
• قرار دادن fluentd (یا آنالوگ) در همان گره با برنامه هایی که لاگ های آنها جمع آوری شده است.
• ...

چنین مسیریابی، که در مورد توپولوژی "می داند"، همچنین قرابت شبکه نامیده می شود - بر اساس قیاس با میل گره, قرابت غلاف/ضد قرابت یا ظاهر شد نه خیلی وقت پیش برنامه ریزی حجمی آگاه از توپولوژی (و تامین حجم). سطح فعلی اجرا ServiceTopology در Kubernetes - نسخه آلفا.

برای جزئیات بیشتر در مورد نحوه عملکرد این ویژگی و نحوه استفاده از آن، بخوانید این مقاله از یکی از نویسندگان

پشتیبانی از دو پشته IPv4/IPv6

پیشرفت قابل توجه درست شد در یکی دیگر از ویژگی های شبکه: پشتیبانی همزمان از دو پشته IP، که برای اولین بار در معرفی شد K8s 1.16. به طور خاص، نسخه جدید تغییرات زیر را به همراه داشت:

• در kube-proxy اجرا شد امکان عملکرد همزمان در هر دو حالت (IPv4 و IPv6).
• в Pod.Status.PodIPs ظاهر شد پشتیبانی از API رو به پایین (همزمان با در /etc/hosts اکنون آنها از میزبان می خواهند که یک آدرس IPv6 اضافه کند).
• پشتیبانی از پشته دوگانه نوع (Kubernetes IN Docker) و kubeadm;
• تست های e2e به روز شده

تصوير با استفاده از دو پشته IPV4/IPv6 در KIND

پیشرفت در CSI

پایدار اعلام کرد پشتیبانی توپولوژی برای ذخیره سازی مبتنی بر CSI، برای اولین بار در K8s 1.12.

ابتکار برای مهاجرت پلاگین های حجمی به CSI - مهاجرت CSI - به نسخه بتا رسیده است. این ویژگی برای ترجمه افزونه های ذخیره سازی موجود حیاتی است (در درخت) به یک رابط مدرن (CSI، خارج از درخت) برای کاربران نهایی Kubernetes نامرئی است. مدیران خوشه فقط باید CSI Migration را فعال کنند، پس از آن منابع و بارهای کاری موجود به حالت "فقط کار می کنند"... اما از آخرین درایورهای CSI به جای درایورهای قدیمی موجود در هسته Kubernetes استفاده می کنند.

در حال حاضر، انتقال برای درایورهای AWS EBS در نسخه بتا آماده است (kubernetes.io/aws-ebs) و GCE PD (kubernetes.io/gce-pd). پیش بینی سایر تاسیسات ذخیره سازی به شرح زیر است:

ما در مورد اینکه چگونه پشتیبانی از حافظه سنتی در K8 به CSI آمد صحبت کردیم این مقاله. و انتقال CSI به وضعیت بتا اختصاص داده شده است انتشار جداگانه در وبلاگ پروژه

علاوه بر این، یکی دیگر از عملکردهای قابل توجه در زمینه CSI، که منشا آن (پیاده سازی آلفا) در K1.17s 8 است، در نسخه Kubernetes 1.12 به وضعیت بتا (یعنی به طور پیش فرض فعال شده است) رسیده است - ایجاد عکس های فوری و بهبودی از آنها. از جمله تغییرات ایجاد شده در Kubernetes Volume Snapshot در راه انتشار بتا:

• تقسیم کردن دوربین عکاسی خارجی CSI به دو کنترلر،
• راز اضافه شده برای حذف (راز حذف) به عنوان یک حاشیه نویسی برای محتوای یک عکس فوری حجم،
• نهایی کننده جدید (نهایی کننده) برای جلوگیری از حذف شی API snapshot در صورت باقی ماندن اتصالات.

در زمان انتشار 1.17، این ویژگی توسط سه درایور CSI پشتیبانی می‌شود: GCE Persistent Disk CSI Driver، Portworx CSI Driver و NetApp Trident CSI Driver. جزئیات بیشتر در مورد پیاده سازی و استفاده از آن را می توان در اینجا یافت این انتشارات در وبلاگ

برچسب های ارائه دهنده ابر

برچسب هایی که به صورت خودکار بسته به ارائه دهنده ابر استفاده شده به گره ها و حجم های ایجاد شده اختصاص داده می شود، برای مدت طولانی - از زمان انتشار K8s 1.2 - در Kubernetes به عنوان یک نسخه بتا در دسترس بوده است. (آوریل 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.

انگیزه اجرای این ویژگی (با توجه به کلاه لبه دار) است:

در حالی که Kubernetes را می توان به صورت دستی مستقر کرد، استاندارد عملی (اگر غیر قانونی) برای این عملیات استفاده از kubeadm است. ابزارهای محبوب مدیریت سیستم مانند Terraform برای استقرار Kubernetes به kubeadm متکی هستند. بهبودهای برنامه ریزی شده برای Cluster API شامل یک بسته قابل ترکیب برای بوت استرپینگ Kubernetes با kubeadm و cloud-init است.

بدون خروجی ساختاریافته، حتی بی ضررترین تغییرات در نگاه اول می تواند Terraform، Cluster API و سایر نرم افزارهایی را که از نتایج kubeadm استفاده می کنند، خراب کند.

برنامه های فوری ما شامل پشتیبانی (به شکل خروجی ساختاریافته) برای دستورات 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 با شعار " انجام شد.ثبات" این با این واقعیت تسهیل شد که بسیاری از ویژگی های موجود در آن (تعداد کل آنها است 14) وضعیت GA را دریافت کرد. از جمله:

• "علامت گذاری" گره ها با توجه به شرایط خاص (TaintNodesByCondition) ظاهر شد K8s 1.8;
• تماشای نشانک ها - نوع جدیدی از رویدادها که دارای برچسبی هستند که همه اشیا تا یک نسخه خاص هستند (resourceVersion) قبلاً توسط ساعت پردازش شده است.
• مقادیر پیش فرض (پیش‌فرض) برای منابع سفارشی.
• به اشتراک گذاشته شده بین ظروف در فضاهای نام فرآیند غلاف؛
• ScheduleDaemonSetPods - غلاف های زمان بندی در DaemonSet استفاده از kube-scheduler (به جای کنترلر DaemonSet)؛
• محدودیت های پویا در تعداد جلدها بسته به نوع گره؛
• پشتیبانی از متغیرهای محیطی برای نام دایرکتوری نصب شده به عنوان subPath;
• انتقال ضربان قلب Kubelet به یک API تخصصی اجاره؛
• "حفاظت نهایی کننده" (محافظت نهایی ساز) برای متعادل کننده های بار (بررسی منابع سرویس مربوطه قبل از حذف منابع LoadBalancer)؛
• بهینه سازی kube-apiserver در عملکرد هنگام کار با ساعت‌های متعدد نظارت بر مجموعه‌های یکسان از اشیاء - با اجتناب از سریال‌سازی مکرر اشیاء مشابه برای هر تماشاگر به دست می‌آید.

تغییرات دیگر

البته لیست کامل نوآوری های Kubernetes 1.17 به موارد ذکر شده در بالا محدود نمی شود. در اینجا چند مورد دیگر وجود دارد (و برای فهرست کامل تر، نگاه کنید تغییر دهید):

• ویژگی ارائه شده در آخرین نسخه به نسخه بتا رسیده است RunAsUserName برای پنجره ها;
• تغییر مشابه اتفاق افتاد EndpointSlice API (همچنین از K8s 1.16)، اما در حال حاضر این راه حل برای بهبود عملکرد/ مقیاس پذیری Endpoint API به طور پیش فرض فعال نیست.
• غلاف ها اکنون برای عملیات خوشه ای حیاتی هستند می توان ایجاد کرد نه تنها در فضاهای نام kube-system (برای جزئیات، به مستندات مربوطه مراجعه کنید مصرف کلاس اولویت را محدود کنید);
• گزینه جدید برای kubelet - --reserved-cpus - به شما امکان می دهد لیست CPU های رزرو شده برای سیستم را به صراحت تعریف کنید.
• برای kubectl logs ارایه شده پرچم جدید --prefix، نام غلاف و محفظه منبع را به هر خط از گزارش اضافه کنید.
• в label.Selector اضافه RequiresExactMatch;
• همه کانتینرها در kube-dns اکنون در حال اجرا هستند با امتیازات کمتر؛
• هایپرکوب در یک مخزن جداگانه GitHub جدا شده و دیگر در نسخه های Kubernetes گنجانده نمی شود.
• بسیار عملکرد بهبود یافته kube-proxy برای پورت های غیر UDP.

تغییرات وابستگی:

• نسخه CoreDNS موجود در kubeadm 1.6.5 است.
• نسخه crictl به نسخه 1.16.1 به روز شد.
• CSI 1.2.0;
• etcd 3.4.3;
• آخرین نسخه آزمایش شده Docker به 19.03 ارتقا یافته است.
• حداقل نسخه Go مورد نیاز برای ساخت Kubernetes 1.17 1.13.4 است.

PS

در وبلاگ ما نیز بخوانید:

• «Kubernetes 1.16: نکات برجسته از آنچه جدید است"؛
• «Kubernetes 1.15: نکات برجسته از آنچه جدید است"؛
• «Kubernetes 1.14: نکات برجسته از آنچه جدید است"؛
• «Kubernetes 1.13: نکات برجسته از آنچه جدید است'.

منبع: www.habr.com