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

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

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

بیایید با یک مقدمه مهم از چرخه حیات خوشه SIG شروع کنیم: خوشه های شکست پویا Kubernetes (یا به عبارت دقیق‌تر، استقرارهای HA با میزبانی خود) در حال حاضر است شما می توانید ایجاد کنید با استفاده از دستورات آشنا (در زمینه خوشه های تک گره). kubeadm (init и join). خلاصه برای این:

• گواهی های استفاده شده توسط خوشه به اسرار منتقل می شود.
• برای امکان استفاده از خوشه etcd در داخل خوشه K8s (یعنی خلاص شدن از وابستگی خارجی قبلی) اپراتور etcd;
• تنظیمات توصیه شده برای متعادل کننده بار خارجی را مستند می کند که پیکربندی مقاوم در برابر خطا را ارائه می دهد (در آینده برنامه ریزی شده است که این وابستگی حذف شود، اما نه در این مرحله).

معماری یک خوشه Kubernetes HA ایجاد شده با kubeadm

جزئیات پیاده سازی را می توان در پیدا کرد پیشنهاد طراحی. این ویژگی واقعاً مدتها مورد انتظار بود: نسخه آلفا در K8s 1.9 انتظار می رفت، اما اکنون ظاهر شد.

API

تیم apply و به طور کلی مدیریت اشیاء اعلامی گذشت از kubectl در apiserver خود توسعه دهندگان به طور خلاصه تصمیم خود را با گفتن آن توضیح می دهند kubectl apply - بخش اساسی کار با پیکربندی ها در Kubernetes، با این حال، "پر از اشکال است و رفع آن دشوار است" و بنابراین این عملکرد باید به حالت عادی برگردد و به صفحه کنترل منتقل شود. نمونه های ساده و واضحی از مشکلاتی که امروزه وجود دارد:

جزئیات پیاده سازی در کلاه لبه دار. آمادگی فعلی آلفا است (ارتقا به بتا برای نسخه بعدی Kubernetes برنامه ریزی شده است).

در نسخه آلفا موجود است فرصت با استفاده از طرح OpenAPI v3 برای ایجاد و انتشار اسناد OpenAPI برای CustomResources (CR) برای اعتبارسنجی (سمت سرور) منابع تعریف شده توسط کاربر K8s (CustomResourceDefinition، CRD) استفاده می شود. انتشار OpenAPI برای CRD به مشتریان اجازه می دهد (به عنوان مثال. kubectl) اعتبارسنجی را از طرف خود انجام دهید (در داخل kubectl create и kubectl apply) و مستندات را طبق طرح صادر کنید (kubectl explain). جزئیات - در کلاه لبه دار.

لاگ های از قبل موجود اکنون باز می شوند با پرچم O_APPEND (اما نه O_TRUNC) برای جلوگیری از از دست دادن سیاههها در برخی شرایط و برای راحتی کوتاه کردن سیاههها با ابزارهای خارجی برای چرخش.

همچنین در زمینه Kubernetes API، می توان اشاره کرد که در PodSandbox и PodSandboxStatus اضافه میدان runtime_handler برای ثبت اطلاعات در مورد RuntimeClass در غلاف (اطلاعات بیشتر در مورد آن را در متن در مورد انتشار Kubernetes 1.12، جایی که این کلاس به عنوان یک نسخه آلفا ظاهر شد)، و در Admission Webhooks اجرا شد توانایی تعیین نسخه ها AdmissionReview آنها حمایت می کنند. در نهایت، قوانین Admission Webhooks اکنون هستند می تواند محدود شود میزان استفاده از آنها توسط فضاهای نام و چارچوب های خوشه ای.

خزانه

PersistentLocalVolumes، که از زمان انتشار وضعیت بتا داشت K8s 1.10, اعلام کرد stable (GA): این گیت ویژگی دیگر غیرفعال نیست و در Kubernetes 1.17 حذف خواهد شد.

فرصت با استفاده از متغیرهای محیطی به نام API رو به پایین (به عنوان مثال، نام pod) برای نام دایرکتوری های نصب شده به عنوان subPath، توسعه یافت - در قالب یک زمینه جدید subPathExpr، که اکنون برای تعیین نام دایرکتوری مورد نظر استفاده می شود. این ویژگی ابتدا در Kubernetes 1.11 ظاهر شد، اما برای 1.14 در وضعیت نسخه آلفا باقی ماند.

همانند نسخه قبلی Kubernetes، بسیاری از تغییرات قابل توجه برای CSI (رابط ذخیره سازی کانتینر) به طور فعال در حال توسعه معرفی شده است:

CSI

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

یکی دیگر از ویژگی های CSI در نسخه آلفا - فرصت به طور مستقیم (یعنی بدون استفاده از PV/PVC) به حجم های CSI در مشخصات غلاف مراجعه کنید. این محدودیت استفاده از CSI به‌عنوان ذخیره‌سازی منحصراً از راه دور داده را حذف می‌کند، درهای جهان را به روی آنها باز می کند حجم های زودگذر محلی. برای استفاده (مثال از مستندات) باید فعال باشد CSIInlineVolume دروازه ویژگی

همچنین پیشرفت هایی در "داخلی" Kubernetes مربوط به CSI وجود دارد که برای کاربران نهایی (مدیران سیستم) چندان قابل مشاهده نیست ... در حال حاضر، توسعه دهندگان مجبور به پشتیبانی از دو نسخه از هر افزونه ذخیره سازی هستند: یکی - "در روش قدیمی»، در پایگاه کد K8s (در درخت)، و دوم - به عنوان بخشی از CSI جدید (مثلاً در مورد آن بیشتر بخوانید اینجا). این باعث ناراحتی های قابل درک می شود که باید با تثبیت خود CSI برطرف شوند. نمی توان به سادگی از API پلاگین های داخلی (در درخت) استفاده کرد خط مشی مربوط به Kubernetes.

همه اینها به این واقعیت منجر شد که نسخه آلفا رسید فرآیند مهاجرت کد داخلی افزونه، به صورت درون درختی در پلاگین های CSI پیاده سازی شده است که به لطف آن نگرانی توسعه دهندگان به پشتیبانی از یک نسخه از افزونه های آنها کاهش می یابد و سازگاری با API های قدیمی باقی می ماند و می توان آنها را در سناریوی معمول منسوخ اعلام کرد. انتظار می‌رود که تا انتشار بعدی Kubernetes (1.15) همه افزونه‌های ارائه‌دهنده ابر منتقل شوند، پیاده‌سازی وضعیت بتا دریافت کند و به طور پیش‌فرض در نصب‌های K8s فعال شود. برای جزئیات، نگاه کنید پیشنهاد طراحی. این مهاجرت نیز منجر شد شکست از محدودیت های حجم تعریف شده توسط ارائه دهندگان ابر خاص (AWS، Azure، GCE، Cinder).

علاوه بر این، پشتیبانی از دستگاه های بلوک با CSI (CSIBlockVolume) منتقل شده به نسخه بتا

Nodes/Kubelet

نسخه آلفا ارائه شده است نقطه پایانی جدید در Kubelet، طراحی شده برای معیارهای بازگشت منابع کلیدی. به طور کلی، اگر قبلاً Kubelet آماری در مورد استفاده از کانتینر از cAdvisor دریافت می کرد، اکنون این داده ها از محیط زمان اجرا کانتینر از طریق CRI (رابط زمان اجرای کانتینر) می آیند، اما سازگاری برای کار با نسخه های قدیمی Docker نیز حفظ می شود. پیش از این، آمار جمع‌آوری‌شده در Kubelet از طریق REST API ارسال می‌شد، اما اکنون یک نقطه پایانی واقع در /metrics/resource/v1alpha1. استراتژی بلند مدت توسعه دهندگان تشکیل شده است به حداقل رساندن مجموعه معیارهای ارائه شده توسط Kubelet است. به هر حال، خود این معیارها الان زنگ میزنن نه "معیارهای اصلی"، بلکه "سنجه های منابع"، و به عنوان "منابع درجه یک، مانند cpu و حافظه" توصیف می شوند.

نکته بسیار جالب: علیرغم مزیت عملکرد واضح نقطه پایانی gRPC در مقایسه با موارد مختلف استفاده از فرمت Prometheus (نتیجه یکی از معیارهای زیر را ببینید)، نویسندگان قالب متن پرومتئوس را به دلیل رهبری واضح این سیستم نظارتی در جامعه ترجیح دادند.

"gRPC با خطوط لوله نظارتی اصلی سازگار نیست. نقطه پایانی فقط برای تحویل معیارها به سرور Metrics یا نظارت بر مؤلفه‌هایی که مستقیماً با آن ادغام می‌شوند مفید خواهد بود. عملکرد فرمت متن Prometheus هنگام استفاده از کش در سرور Metrics به اندازه کافی خوب با توجه به پذیرش گسترده پرومتئوس در جامعه، پرومتئوس را بر gRPC ترجیح دهیم. هنگامی که فرمت OpenMetrics پایدارتر شد، می‌توانیم عملکرد gRPC را با یک قالب مبتنی بر پروتو نزدیک کنیم.

یکی از تست های عملکرد مقایسه ای استفاده از فرمت های gRPC و Prometheus در نقطه پایانی جدید Kubelet برای معیارها. نمودارهای بیشتر و جزئیات دیگر را می توان در این قسمت یافت کلاه لبه دار.

از جمله تغییرات دیگر:

• Kubelet اکنون (یک بار) تلاش برای متوقف کردن کانتینرها در حالت ناشناخته قبل از شروع مجدد و حذف عملیات.
• هنگام استفاده از PodPresets اکنون به ظرف اولیه اضافه همان اطلاعات یک ظرف معمولی.
• کوبلت شروع به استفاده کرد usageNanoCores از ارائه دهنده آمار CRI، و برای گره ها و کانتینرها در ویندوز اضافه آمار شبکه
• اطلاعات سیستم عامل و معماری اکنون در برچسب ها ثبت می شود kubernetes.io/os и kubernetes.io/arch اشیاء گره (از بتا به GA منتقل می شوند).
• امکان تعیین یک گروه کاربری خاص سیستم برای کانتینرها در یک پاد (RunAsGroup، ظاهر شد K8s 1.11) پیشرفته قبل از بتا (به طور پیش فرض فعال است).
• du و find مورد استفاده در cAdvisor، جایگزین شده است پیاده سازی on Go.

CLI

در cli-runtime و kubectl اضافه -k پرچم برای ادغام با سفارشی کردن (به هر حال، توسعه آن اکنون در یک مخزن جداگانه انجام می شود)، یعنی. برای پردازش فایل‌های YAML اضافی از دایرکتوری‌های شخصی‌سازی ویژه (برای جزئیات بیشتر در مورد استفاده از آنها، رجوع کنید به کلاه لبه دار):

مثالی از استفاده ساده از فایل سفارشی سازی (کاربرد پیچیده تری از kustomize در داخل امکان پذیر است پوشش)

علاوه بر این:

• اضافه تیم جدید kubectl create cronjob، که نامش گویای خودش است.
• В kubectl logs حالا می توانید برای ترکیب کردن پرچم ها -f (--follow برای گزارش های جریان) و -l (--selector برای درخواست برچسب).
• کوبکتل تدریس کپی فایل های انتخاب شده توسط کارت وحشی.
• به تیم kubectl wait اضافه پرچم --all برای انتخاب تمام منابع در فضای نام نوع منبع مشخص شده.

دیگران

قابلیت های زیر وضعیت پایدار (GA) دریافت کرده اند:

• ReadinessGate، در مشخصات غلاف برای تعریف شرایط اضافی در نظر گرفته شده در آمادگی غلاف استفاده می شود.
• پشتیبانی از صفحات بزرگ (ویژگی گیت نامیده می شود HugePages);
• CustomPodDNS;
• PriorityClass API Pod Priority & Preemption.

سایر تغییرات معرفی شده در Kubernetes 1.14:

• خط مشی پیش‌فرض RBAC دیگر اجازه دسترسی به API را نمی‌دهد discovery и access-review کاربران بدون احراز هویت (بدون احراز هویت).
• پشتیبانی رسمی CoreDNS تضمین شده است فقط لینوکس، بنابراین هنگام استفاده از kubeadm برای استقرار آن (CoreDNS) در یک کلاستر، گره‌ها فقط باید روی لینوکس اجرا شوند (nodeSelectors برای این محدودیت استفاده می‌شود).
• پیکربندی پیش‌فرض CoreDNS اکنون است استفاده می کند افزونه فوروارد به جای پروکسی همچنین در CoreDNS اضافه ReadinessProbe، که از تعادل بار روی غلاف های مناسب (آماده برای سرویس) جلوگیری می کند.
• در kubeadm، روی فازها init یا upload-certs, ممکن شد بارگذاری گواهینامه های مورد نیاز برای اتصال صفحه کنترل جدید به راز kubeadm-certs (از پرچم استفاده کنید --experimental-upload-certs).
• یک نسخه آلفا برای نصب ویندوز ظاهر شده است پشتیبانی gMSA (حساب سرویس مدیریت شده گروهی) - حساب های ویژه در Active Directory که می توانند توسط کانتینرها نیز استفاده شوند.
• برای G.C.E. فعال شد رمزگذاری mTLS بین etcd و kube-apiserver.
• به روز رسانی در نرم افزارهای استفاده شده/وابسته: Go 1.12.1، CSI 1.1، CoreDNS 1.3.1، پشتیبانی از Docker 18.09 در kubeadm، و حداقل نسخه پشتیبانی شده Docker API اکنون 1.26 است.

PS

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

• «Kubernetes 1.13: نکات برجسته از آنچه جدید است"؛
• «Kubernetes 1.12: نکات برجسته از آنچه جدید است"؛
• «Kubernetes 1.11: نکات برجسته از آنچه جدید است"؛
• «Kubernetes 1.10: نکات برجسته از آنچه جدید است'.

منبع: www.habr.com