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

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

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

گره ها

تعداد بسیار زیادی از نوآوری های قابل توجه (در وضعیت نسخه آلفا) در کنار گره های خوشه ای K8s (Kubelet) ارائه شده است.

اولا، به اصطلاح «ظروف زودگذر» (ظروف زودگذر)طراحی شده برای ساده سازی فرآیندهای اشکال زدایی در پادها. مکانیسم جدید به شما امکان می دهد کانتینرهای ویژه ای را راه اندازی کنید که در فضای نام غلاف های موجود شروع شده و برای مدت کوتاهی زندگی می کنند. هدف آنها تعامل با سایر غلاف ها و ظروف به منظور حل هر گونه مشکل و اشکال زدایی است. دستور جدیدی برای این قابلیت پیاده سازی شده است kubectl debug، در اصل شبیه به kubectl exec: فقط به جای اجرای یک فرآیند در یک ظرف (مانند exec) ظرفی را در غلاف راه اندازی می کند. به عنوان مثال، این دستور یک کانتینر جدید را به یک pod متصل می کند:

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

جزئیات مربوط به ظروف زودگذر (و نمونه هایی از استفاده از آنها) را می توان در اینجا یافت KEP مربوطه. پیاده‌سازی فعلی (در K8s 1.16) یک نسخه آلفا است و یکی از معیارهای انتقال آن به نسخه بتا، «آزمایش API Ephemeral Containers برای حداقل 2 نسخه [Kubernetes] است».

NB: این ویژگی در اصل و حتی نامش شبیه یک افزونه از قبل موجود است kubectl-debugکه در مورد آن ما قبلا نوشته بود. انتظار می رود با ظهور کانتینرهای زودگذر، توسعه یک افزونه خارجی جداگانه متوقف شود.

یک نوآوری دیگر - PodOverhead - طراحی شده برای ارائه مکانیزم برای محاسبه هزینه های سربار برای غلاف، که بسته به زمان اجرا استفاده شده می تواند بسیار متفاوت باشد. به عنوان نمونه، نویسندگان این KEP منجر به کانتینرهای کاتا می شود که نیاز به اجرای هسته مهمان، عامل کاتا، سیستم init و غیره دارند. وقتی سربار آنقدر زیاد می شود، نمی توان آن را نادیده گرفت، به این معنی که باید راهی برای در نظر گرفتن آن برای سهمیه های بیشتر، برنامه ریزی و غیره وجود داشته باشد. برای پیاده سازی آن در PodSpec فیلد اضافه شد Overhead *ResourceList (مقایسه با داده های موجود در RuntimeClass، در صورت استفاده از یکی).

نوآوری قابل توجه دیگر این است مدیر توپولوژی گره (مدیر توپولوژی گره)طراحی شده برای یکسان کردن رویکرد تنظیم دقیق تخصیص منابع سخت افزاری برای اجزای مختلف در Kubernetes. این ابتکار به دلیل نیاز روزافزون سیستم‌های مختلف مدرن (از حوزه مخابرات، یادگیری ماشین، خدمات مالی و غیره) برای محاسبات موازی با کارایی بالا و به حداقل رساندن تاخیر در اجرای عملیات هدایت می‌شود که برای آن از CPU و پیشرفته استفاده می‌کنند. قابلیت های شتاب سخت افزاری چنین بهینه‌سازی‌هایی در Kubernetes تاکنون به لطف مؤلفه‌های متفاوت (مدیر CPU، مدیر دستگاه، CNI) به دست آمده است، و اکنون یک رابط داخلی واحد به آن‌ها اضافه می‌شود که رویکرد را متحد می‌کند و اتصال مشابه جدید - به اصطلاح توپولوژی- را ساده می‌کند. آگاه - اجزای سمت Kubelet. جزئیات - در KEP مربوطه.

نمودار اجزای مدیر توپولوژی

ویژگی بعدی - چک کردن ظروف در حین کار (کاوشگر راه اندازی). همانطور که می‌دانید، برای کانتینرهایی که راه‌اندازی آنها زمان زیادی طول می‌کشد، به‌روزرسانی وضعیت دشوار است: آنها یا قبل از شروع به کار واقعی "کشته می‌شوند" یا برای مدت طولانی در بن بست قرار می‌گیرند. چک جدید (فعال از طریق ویژگی گیت به نام StartupProbeEnabled) لغو - یا بهتر است بگوییم، - تأثیر سایر بررسی‌ها را تا زمانی که غلاف به پایان برسد، به تعویق می‌اندازد. به همین دلیل، این ویژگی در ابتدا نامیده شد pod-startup liveness-probe holdoff. برای غلاف هایی که شروع به زمان زیادی طول می کشد، می توانید وضعیت را در بازه های زمانی نسبتاً کوتاهی نظرسنجی کنید.

علاوه بر این، یک بهبود برای RuntimeClass بلافاصله در وضعیت بتا در دسترس است و پشتیبانی از «خوشه‌های ناهمگن» را اضافه می‌کند. سی زمان بندی RuntimeClass اکنون اصلاً لازم نیست که هر گره از هر RuntimeClass پشتیبانی کند: برای پادها می‌توانید یک RuntimeClass را بدون فکر کردن به توپولوژی کلاستر انتخاب کنید. پیش از این، برای رسیدن به این هدف - به طوری که پادها به گره‌ها با پشتیبانی از هر چیزی که نیاز دارند ختم شود - لازم بود قوانین مناسبی به NodeSelector و tolerations اختصاص دهیم. که در کلاه لبه دار در مورد نمونه هایی از استفاده و البته جزئیات پیاده سازی صحبت می کند.

شبکه

دو ویژگی مهم شبکه که برای اولین بار (در نسخه آلفا) در Kubernetes 1.16 ظاهر شد عبارتند از:

• پشتیبانی پشته شبکه دوگانه - IPv4/IPv6 - و "درک" مربوط به آن در سطح غلاف ها، گره ها، خدمات. این شامل قابلیت همکاری IPv4 به IPv4 و IPv6 به IPv6 بین پادها، از پادها تا سرویس‌های خارجی، پیاده‌سازی مرجع (در پلاگین‌های Bridge CNI، PTP CNI و Host-Local IPAM)، و همچنین سازگاری معکوس با خوشه‌های Kubernetes در حال اجرا است. فقط IPv4 یا IPv6. جزئیات پیاده سازی درج شده است کلاه لبه دار.

  نمونه ای از نمایش آدرس های 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 جدید برای Endpoint - EndpointSlice 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

"نقطه عطف تثبیت" واقعی در ناحیه سرور API Kubernetes و تعامل با آن است. این اتفاق تا حد زیادی به لطف انتقال به وضعیت پایدار کسانی که نیاز به معرفی خاصی ندارند تعاریف منابع سفارشی (CRD)، که از روزهای دور Kubernetes 1.7 (و این ژوئن 2017 است!) وضعیت بتا داشتند. همان تثبیت به ویژگی های مرتبط رسید:

• "منابع فرعی" با /status и /scale برای منابع سفارشی؛
• تحول نسخه برای CRD، بر اساس webhook خارجی.
• اخیرا ارائه شده است (در K8s 1.15) مقادیر پیش فرض (پیش‌فرض) و حذف خودکار میدان (هرس) برای منابع سفارشی؛
• فرصت با استفاده از طرحواره OpenAPI v3 برای ایجاد و انتشار اسناد OpenAPI مورد استفاده برای اعتبارسنجی منابع CRD در سمت سرور.

مکانیسم دیگری که مدتهاست برای مدیران Kubernetes آشنا شده است: وب هوک پذیرش - همچنین برای مدت طولانی (از K8s 1.9) در وضعیت بتا باقی ماند و اکنون پایدار اعلام شده است.

دو ویژگی دیگر به نسخه بتا رسیده اند: سمت سرور اعمال شود и تماشای نشانک ها.

و تنها نوآوری قابل توجه در نسخه آلفا بود شکست از SelfLink - یک URI ویژه که نشان دهنده شی مشخص شده و بخشی از آن است ObjectMeta и ListMeta (یعنی بخشی از هر شی در Kubernetes). چرا آن را رها می کنند؟ ایجاد انگیزه به روشی ساده صدا به عنوان فقدان دلایل واقعی (قاطع) برای هنوز وجود این رشته. دلایل رسمی تر، بهینه سازی عملکرد (با حذف یک فیلد غیر ضروری) و ساده کردن کار Apiserver عمومی است که مجبور است چنین فیلدی را به روشی خاص مدیریت کند (این تنها فیلدی است که درست قبل از شی تنظیم می شود. سریالی شده است). منسوخ شدن واقعی (در بتا) SelfLink توسط Kubernetes نسخه 1.20 و نهایی - 1.21 اتفاق می افتد.

ذخیره سازی داده ها

کار اصلی در منطقه ذخیره سازی، مانند نسخه های قبلی، در منطقه مشاهده می شود پشتیبانی CSI. تغییرات اصلی در اینجا عبارت بودند از:

• برای اولین بار (در نسخه آلفا) ظاهر شد پشتیبانی از پلاگین CSI برای گره های کارگر ویندوز: روش فعلی کار با ذخیره سازی همچنین جایگزین پلاگین های درون درختی در هسته Kubernetes و افزونه های FlexVolume از مایکروسافت مبتنی بر Powershell می شود.

  
  طرحی برای پیاده سازی پلاگین های CSI در Kubernetes برای ویندوز

• فرصت تغییر اندازه حجم های CSI، که در K8s 1.12 معرفی شد، به نسخه بتا رشد کرده است.
• یک "ترفیع" مشابه (از آلفا به بتا) با توانایی استفاده از CSI برای ایجاد حجم های زودگذر محلی (پشتیبانی از حجم داخلی CSI).

در نسخه قبلی Kubernetes معرفی شده است عملکرد کلونینگ حجمی (با استفاده از PVC موجود به عنوان DataSource برای ایجاد PVC جدید) نیز اکنون وضعیت بتا را دریافت کرده است.

برنامه ریز

دو تغییر قابل توجه در زمان بندی (هر دو به صورت آلفا):

• EvenPodsSpreading - فرصت برای "توزیع عادلانه" بارها به جای واحدهای کاربردی منطقی از غلاف استفاده کنید (مانند Deployment و ReplicaSet) و تنظیم این توزیع (به عنوان یک نیاز سخت یا به عنوان یک شرایط نرم، یعنی اولویت). این ویژگی قابلیت های توزیع موجود در غلاف های برنامه ریزی شده را که در حال حاضر توسط گزینه ها محدود شده است، گسترش می دهد PodAffinity и PodAntiAffinity، کنترل دقیق تری در این مورد به مدیران می دهد که به معنای دسترسی بهتر و مصرف بهینه منابع است. جزئیات - در کلاه لبه دار.
• استفاده خط مشی BestFit в تابع اولویت RequestedToCapacityRatio در طول برنامه ریزی غلاف، که اجازه می دهد اعمال می شود بسته بندی سطل زباله ("بسته بندی در ظروف") هم برای منابع اصلی (پردازنده، حافظه) و هم برای منابع توسعه یافته (مانند GPU). برای جزئیات بیشتر، نگاه کنید کلاه لبه دار.

  
  غلاف‌های زمان‌بندی: قبل از استفاده از خط‌مشی بهترین تناسب (مستقیماً از طریق زمان‌بندی پیش‌فرض) و با استفاده از آن (از طریق توسعه‌دهنده زمان‌بندی)

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

تغییرات دیگر

همچنین در نسخه Kubernetes 1.16 می توان به آن اشاره کرد ابتکار عمل برای به ارمغان آوردن معیارهای موجود به ترتیب کامل، یا به طور دقیق تر، مطابق با مقررات رسمی به ابزار دقیق K8s. آنها تا حد زیادی به موارد مربوطه متکی هستند مستندات پرومتئوس. ناهماهنگی ها به دلایل مختلف به وجود آمد (به عنوان مثال، برخی از معیارها به سادگی قبل از ظاهر شدن دستورالعمل های فعلی ایجاد شدند)، و توسعه دهندگان تصمیم گرفتند که زمان آن رسیده است که همه چیز را به یک استاندارد واحد برسانند، "مطابق با بقیه اکوسیستم پرومتئوس". اجرای فعلی این ابتکار در وضعیت آلفا است که به تدریج در نسخه های بعدی Kubernetes به بتا (1.17) و پایدار (1.18) ارتقا می یابد.

علاوه بر این، می توان به تغییرات زیر اشاره کرد:

• توسعه پشتیبانی ویندوز с ظاهر ابزارهای Kubeadm برای این سیستم عامل (نسخه آلفا)، فرصت RunAsUserName برای کانتینرهای ویندوز (نسخه آلفا)، بهبود پشتیبانی از حساب سرویس مدیریت گروه (gMSA) تا نسخه بتا، حمایت کردن mount/attach برای حجم های vSphere.
• بازیافت شده مکانیسم فشرده سازی داده ها در پاسخ های API. قبلاً از یک فیلتر HTTP برای این اهداف استفاده می شد که تعدادی محدودیت را اعمال می کرد که به طور پیش فرض از فعال شدن آن جلوگیری می کرد. "فشرده سازی درخواست شفاف" اکنون کار می کند: مشتریان ارسال می کنند Accept-Encoding: gzip در هدر، اگر اندازه آن از 128 کیلوبایت بیشتر شود، یک پاسخ فشرده با GZIP دریافت می کنند. مشتریان Go به طور خودکار از فشرده سازی (ارسال هدر مورد نیاز) پشتیبانی می کنند، بنابراین بلافاصله متوجه کاهش ترافیک می شوند. (ممکن است برای سایر زبان ها تغییرات جزئی لازم باشد.)
• ممکن شد مقیاس بندی HPA از/به غلاف صفر بر اساس معیارهای خارجی. اگر بر اساس اشیاء/معیارهای خارجی مقیاس می‌گیرید، وقتی بارهای کاری بی‌حرکت هستند، می‌توانید به‌طور خودکار تا 0 کپی مقیاس کنید تا منابع را ذخیره کنید. این ویژگی باید به ویژه برای مواردی مفید باشد که کارگران منابع GPU را درخواست می کنند و تعداد انواع مختلف کارگران بیکار از تعداد GPUهای موجود بیشتر است.
• مشتری جدید - k8s.io/client-go/metadata.Client - برای دسترسی "عمومی" به اشیا. این طراحی شده است تا به راحتی ابرداده ها را بازیابی کند (به عنوان مثال زیربخش metadata) از منابع خوشه ای و انجام عملیات جمع آوری زباله و سهمیه بندی با آنها.
• Kubernetes را بسازید حالا می توانید بدون ارائه دهندگان ابری (نسخه آلفا) قدیمی («ساخته شده» درون درختی).
• به ابزار kubeadm اضافه توانایی آزمایشی (نسخه آلفا) برای اعمال وصله های سفارشی در طول عملیات init, join и upgrade. درباره نحوه استفاده از پرچم بیشتر بیاموزید --experimental-kustomize، بررسی کلاه لبه دار.
• نقطه پایانی جدید برای apiserver - 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 در تصویر Docker مربوطه ساخته شده world-executable که به شما امکان می دهد این تصویر را بدون نیاز به حقوق ریشه اجرا کنید. همچنین، تصویر مهاجرت etcd متوقف شد پشتیبانی از نسخه etcd2
• В Cluster Autoscaler 1.16.0 تغییر به استفاده از بدون distroless به عنوان تصویر پایه، بهبود عملکرد، اضافه کردن ارائه دهندگان ابر جدید (DigitalOcean، Magnum، Packet).
• به روز رسانی در نرم افزار استفاده شده/وابسته: Go 1.12.9، etcd 3.3.15، CoreDNS 1.6.2.

PS

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

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

منبع: www.habr.com