Kubernetes 1.16: преглед на главните иновации

Денес, среда, се одвива следно издание на Kubernetes - 1.16. Според традицијата што се разви за нашиот блог, ова е десетгодишнина кога зборуваме за најзначајните промени во новата верзија.

Информациите што се користат за подготовка на овој материјал се земени од Табели за следење подобрувања на Кубернет, CHANGELOG-1.16 и поврзани прашања, барања за повлекување и предлози за подобрување на Kubernetes (KEP). Па, ајде да одиме!..

Јазли

Навистина голем број забележителни иновации (во статусот на алфа верзија) се претставени на страната на јазлите на кластерот K8s (Kubelet).

Прво, т.н «ефемерни контејнери» (Ефемерни контејнери), дизајниран да ги поедностави процесите на дебагирање во pods. Новиот механизам ви овозможува да лансирате специјални контејнери кои започнуваат во именскиот простор на постоечките мешунки и живеат кратко време. Нивната цел е да комуницираат со други мешунки и контејнери со цел да се решат сите проблеми и да се дебагираат. За оваа функција е имплементирана нова команда kubectl debug, сличен во суштина на kubectl exec: само наместо да се води процес во контејнер (како во exec) лансира контејнер во мешунка. На пример, оваа команда ќе поврзе нов контејнер со pod:

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

Детали за ефемерните контејнери (и примери за нивна употреба) може да се најдат во соодветниот КЕП. Тековната имплементација (во K8s 1.16) е алфа верзија, а меѓу критериумите за нејзино пренесување во бета верзија е „тестирање на Ephemeral Containers API за најмалку 2 изданија на [Kubernetes]“.

NB: Во својата суштина, па дури и неговото име, функцијата наликува на веќе постоечки приклучок kubectl-debugза кои ние веќе напиша. Се очекува дека со доаѓањето на ефемерните контејнери, развојот на посебен надворешен приклучок ќе престане.

Уште една иновација - PodOverhead - дизајниран да обезбеди механизам за пресметување на режиските трошоци за мешунките, што може многу да варира во зависност од употребеното време на работа. Како пример, авторите овој КЕП резултираат со ката контејнери, за кои е потребно да се стартува гостинското јадро, ката агентот, иницијалниот систем итн. Кога трошоците стануваат толку големи, не може да се игнорираат, што значи дека треба да се има начин да се земе предвид за понатамошни квоти, планирање итн. Да се ​​имплементира во PodSpec додадено поле Overhead *ResourceList (се споредува со податоците во RuntimeClass, ако се користи).

Друга забележителна иновација е менаџер на топологија на јазол (Менаџер за топологија на јазол), дизајниран да го обедини пристапот за прецизно прилагодување на распределбата на хардверските ресурси за различни компоненти во Kubernetes. Оваа иницијатива е поттикната од зголемената потреба од различни современи системи (од областа на телекомуникациите, машинското учење, финансиските услуги итн.) за паралелно пресметување со високи перформанси и минимизирање на доцнењата во извршувањето на операциите, за што користат напредни процесорски и способности за хардверско забрзување. Ваквите оптимизации во Kubernetes досега беа постигнати благодарение на различните компоненти (CPU менаџер, Device manager, CNI), а сега ќе им биде додаден единствен внатрешен интерфејс кој го обединува пристапот и го поедноставува поврзувањето на нови слични - т.н. топологија- свесни - компоненти на страната Кубелет. Детали - во соодветниот КЕП.

Дијаграм на компоненти на менаџерот за топологија

Следна карактеристика - проверка на контејнерите додека работат (сонда за стартување). Како што знаете, за контејнерите на кои им треба долго време да се пуштат, тешко е да се добие ажуриран статус: или се „убиени“ пред да почнат да функционираат или завршуваат во ќорсокак долго време. Нова проверка (овозможена преку повикана порта за функции StartupProbeEnabled) го откажува - или подобро кажано, го одложува - ефектот на сите други проверки до моментот кога подлогата не заврши со работа. Поради оваа причина, функцијата првично беше наречена pod-startup liveness-probe holdoff. За мешунките за кои е потребно долго време да се стартуваат, можете да ја испитате состојбата во релативно кратки временски интервали.

Дополнително, подобрувањето за RuntimeClass е веднаш достапно во бета статус, додавајќи поддршка за „хетерогени кластери“. В Распоред на RuntimeClass Сега воопшто не е неопходно секој јазол да има поддршка за секоја RuntimeClass: за подови можете да изберете RuntimeClass без да размислувате за топологијата на кластерот. Претходно, за да се постигне ова - така што pods завршуваат на јазли со поддршка за сè што им е потребно - беше неопходно да се доделат соодветни правила на NodeSelector и толеранции. ВО KEP Зборува за примери на употреба и, се разбира, детали за имплементација.

Мрежа

Две значајни мрежни карактеристики кои се појавија за прв пат (во алфа верзија) во Kubernetes 1.16 се:

• Поддршка двоен мрежен стек - IPv4/IPv6 - и неговото соодветно „разбирање“ на ниво на мешунки, јазли, услуги. Вклучува интероперабилност IPv4-to-IPv4 и IPv6-to-IPv6 помеѓу подлоги, од подлоги до надворешни услуги, референтни имплементации (во рамките на Bridge CNI, PTP CNI и Host-Local IPAM приклучоците), како и обратна компатибилност со кластерите Kubernetes кои работат Само IPv4 или IPv6. Деталите за имплементацијата се во KEP.

  Пример за прикажување на 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 ќе биде додаден во групата Discovery API и ќе може да опслужува десетици илјади задни крајни точки на секоја услуга во кластер кој се состои од илјадници јазли. За да го направите ова, секоја услуга е мапирана со N објекти EndpointSlice, од кои секоја стандардно нема повеќе од 100 крајни точки (вредноста може да се конфигурира). EndpointSlice API, исто така, ќе обезбеди можности за неговиот иден развој: поддршка за повеќе IP адреси за секој pod, нови состојби за крајните точки (не само Ready и NotReady), динамична подпоставка за крајните точки.

Она што беше претставено во последното издание стигна до бета верзијата финализатор, именуван service.kubernetes.io/load-balancer-cleanup и се прикачува на секоја услуга со тип LoadBalancer. Во моментот на бришење на таква услуга, го спречува вистинското бришење на ресурсот додека не заврши „чистењето“ на сите релевантни ресурси за балансирање.

API машини

Вистинската „пресвртница за стабилизација“ е во областа на серверот Kubernetes API и интеракцијата со него. Ова се случи во голема мера благодарение на пренесување во стабилен статус на оние на кои не им треба посебен вовед Прилагодени дефиниции на ресурси (CRD), кои имаат бета статус уште од далечните денови на Kubernetes 1.7 (а ова е јуни 2017 година!). Истата стабилизација дојде до поврзаните карактеристики:

• „подизвори“ со /status и /scale за CustomResources;
• трансформација верзии за CRD, базирани на надворешна веб-кука;
• неодамна претставени (во K8s 1.15) стандардни вредности (стандардно) и автоматско отстранување на полето (кроење) за CustomResources;
• можност користејќи ја шемата OpenAPI v3 за креирање и објавување на документацијата OpenAPI што се користи за валидација на ресурсите на CRD на страната на серверот.

Друг механизам што одамна им стана познат на администраторите на Кубернетес: веб-кука за прием - исто така остана во бета статус долго време (од K8s 1.9) и сега е прогласен за стабилен.

Две други функции стигнаа до бета: се применува од страна на серверот и обележувачи за гледање.

И единствената значајна иновација во алфа верзијата беше неуспех од SelfLink — специјален URI што го претставува наведениот објект и е дел од ObjectMeta и ListMeta (т.е. дел од кој било објект во Кубернетес). Зошто го напуштаат? Мотивација на едноставен начин звуци како отсуство на реални (повеќе) причини ова поле сè уште да постои. Поформални причини се да се оптимизираат перформансите (со отстранување на непотребното поле) и да се поедностави работата на генеричкиот аписсервер, кој е принуден да ракува со такво поле на посебен начин (ова е единственото поле што е поставено веднаш пред објектот е серијализиран). Вистинска застареност (во рамките на бета) SelfLink ќе се случи со Kubernetes верзија 1.20, а конечна - 1.21.

Складирање на податоци

Главната работа во областа на складирање, како и во претходните изданија, е забележана во областа CSI поддршка. Главните промени тука беа:

• за прв пат (во алфа верзија) се појави Поддршка за CSI приклучок за работнички јазли на Windows: сегашниот начин на работа со складирање, исто така, ќе ги замени приклучоците во дрвото во јадрото на Kubernetes и приклучоците FlexVolume од Microsoft базирани на Powershell;

  
  Шема за имплементација на CSI приклучоци во Kubernetes за Windows

• можност промена на големината на тома на CSI, воведен уште во K8s 1.12, прерасна во бета верзија;
• Слична „промоција“ (од алфа до бета) беше постигната со можноста да се користи CSI за да се создадат локални ефемерни волумени (Поддршка за Вграден волумен на CSI).

Воведен во претходната верзија на Kubernetes функција за клонирање на волумен (со користење на постоечки ПВЦ како DataSource да се создаде нов ПВЦ) исто така сега доби бета статус.

Распоредувач

Две забележителни промени во распоредот (и во алфа):

• EvenPodsSpreading - можност користете подлоги наместо логички апликативни единици за „фер распределба“ на оптоварувањата (како Deployment и ReplicaSet) и прилагодување на оваа дистрибуција (како тешко барање или како мека состојба, т.е. приоритет). Функцијата ќе ги прошири постојните можности за дистрибуција на планираните подлоги, моментално ограничени со опции PodAffinity и PodAntiAffinity, давајќи им на администраторите подобра контрола во ова прашање, што значи подобра висока достапност и оптимизирана потрошувачка на ресурси. Детали - во KEP.
• Користете Политика на BestFit в Приоритетна функција RequestedTo Capacity Ratio за време на планирањето на мешунките, што ќе овозможи да се примени пакување за канти („пакување во контејнери“) и за основните ресурси (процесор, меморија) и за проширените (како графичкиот процесор). За повеќе детали, видете KEP.

  
  Распоред на подлоги: пред да се користи политиката за најдобро одговарање (директно преку стандардниот распоредувач) и со негова употреба (преку продолжувачот на распоредувачот)

Покрај тоа, е претставен способноста да креирате сопствени приклучоци за распоредувач надвор од главното развојно дрво на Кубернетес (надвор од дрвото).

Други промени

Може да се забележи и во изданието Kubernetes 1.16 иницијатива за носење достапни метрики во полн ред, или поточно, во согласност со официјалните прописи до инструментацијата K8s. Тие во голема мера се потпираат на соодветните Прометеј документација. Недоследностите се појавија од различни причини (на пример, некои метрики беа едноставно создадени пред да се појават тековните инструкции), а програмерите одлучија дека е време да донесат сè на единствен стандард, „во согласност со остатокот од екосистемот Прометеј“. Тековната имплементација на оваа иницијатива е во алфа статус, која постепено ќе се промовира во следните верзии на Kubernetes во бета (1.17) и стабилна (1.18).

Покрај тоа, може да се забележат следните промени:

• Windows поддршка за развој с изглед Kubeadm алатки за овој оперативен систем (алфа верзија), можност RunAsUserName за контејнери на Windows (алфа верзија), подобрување Поддршка до бета верзија на групна управувана услуга сметка (gMSA), поддршка монтирање/прикачување за тома на vSphere.
• Рециклирано механизам за компресија на податоци во одговорите на API. Претходно, за овие цели се користеше HTTP филтер, кој наметна голем број ограничувања што го оневозможуваа стандардно да се овозможи. „Транспарентна компресија на барање“ сега работи: клиентите испраќаат Accept-Encoding: gzip во заглавието, тие добиваат GZIP-компресиран одговор ако неговата големина надминува 128 KB. Go клиентите автоматски поддржуваат компресија (испраќање на потребното заглавие), така што веднаш ќе забележат намалување на сообраќајот. (Можеби ќе бидат потребни мали измени за други јазици.)
• Стана возможно скалирање на HPA од/до нула мешунки врз основа на надворешни метрики. Ако скалирате врз основа на објекти/надворешни метрики, тогаш кога работните оптоварувања се неактивен, можете автоматски да скалирате до 0 реплики за да заштедите ресурси. Оваа функција треба да биде особено корисна за случаи кога работниците бараат ресурси на графичкиот процесор, а бројот на различни типови работници во мирување го надминува бројот на достапни графички процесори.
• Нов клиент - k8s.io/client-go/metadata.Client — за „генерализиран“ пристап до објекти. Дизајниран е за лесно враќање на метаподатоците (т.е. потсекција metadata) од кластерските ресурси и со нив врши операции за собирање и квоти на смет.
• Изградете Kubernetes сега можеш без наследени („вградени“ во дрво) даватели на облак (алфа верзија).
• До алатката kubeadm додаде експериментална (алфа верзија) способност за примена на приспособени закрпи за време на операциите init, join и upgrade. Дознајте повеќе за тоа како да го користите знамето --experimental-kustomize, види во KEP.
• Нова крајна точка за apiserver - readyz, - ви овозможува да извезувате информации за неговата подготвеност. Серверот API, исто така, сега има знаменце --maximum-startup-sequence-duration, овозможувајќи ви да го регулирате неговото рестартирање.
• Две карактеристики за Azure прогласена за стабилна: поддршка зони на достапност (Зони на достапност) и вкрстена ресурсна група (РГ). Покрај тоа, Azure додаде:
  • поддршка за автентикација AAD и ADFS;
  • прибелешка service.beta.kubernetes.io/azure-pip-name да се специфицира јавната IP адреса на балансерот на оптоварување;
  • можност поставувања LoadBalancerName и LoadBalancerResourceGroup.
• AWS сега има поддршка за EBS на Windows и оптимизиран Повици на EC2 API DescribeInstances.
• Kubeadm сега е независен мигрира Конфигурација на CoreDNS при надградба на верзијата CoreDNS.
• Бинарни итн во соодветната слика на Docker направено world-executable, што ви овозможува да ја извршите оваа слика без потреба од права на root. Исто така, слика за миграција итн престана Поддршка за верзијата etcd2.
• В Cluster Autoscaler 1.16.0 се префрли на користење без дистрибуција како основна слика, подобрени перформанси, додадени нови даватели на облак (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