🥇Кубернетес 1.16: преглед главних иновација

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

Информације које се користе за припрему овог материјала су преузете из Табеле за праћење Кубернетес побољшања, ЦХАНГЕЛОГ-1.16 и сродна питања, захтеви за повлачење и предлози за побољшање Кубернетеса (КЕП). Па идемо!..

Чворови

Заиста велики број значајних иновација (у статусу алфа верзије) представљен је на страни чворова кластера К8с (Кубелет).

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

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

Детаљи о ефемерним контејнерима (и примери њихове употребе) могу се наћи у одговарајући КЕП. Тренутна имплементација (у К8с 1.16) је алфа верзија, а међу критеријумима за њен пренос у бета верзију је „тестирање АПИ-ја ефемерних контејнера за најмање 2 издања [Кубернетеса].“

NB: У својој суштини, па чак и по имену, ова функција подсећа на већ постојећи додатак кубецтл-дебуго чему ми већ написао. Очекује се да ће са појавом ефемерних контејнера престати развој посебног екстерног додатка.

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

Још једна значајна иновација је менаџер топологије чвора (Управитељ топологије чворова), дизајниран да обједини приступ фином подешавању алокације хардверских ресурса за различите компоненте у Кубернетес-у. Ова иницијатива је вођена растућом потребом различитих савремених система (из области телекомуникација, машинског учења, финансијских услуга, итд.) за паралелно рачунарство високих перформанси и минимизирање кашњења у извршавању операција, за које користе напредне ЦПУ и могућности хардверског убрзања. Овакве оптимизације у Кубернетес-у су до сада постигнуте захваљујући различитим компонентама (ЦПУ менаџер, Девице манагер, ЦНИ), а сада ће им бити додат један интерни интерфејс који обједињује приступ и поједностављује повезивање нових сличних – тзв. свесни - компоненте на страни Кубелета. Детаљи - ин одговарајући КЕП.

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

Следећа карактеристика - провера контејнера док раде (стартуп сонда). Као што знате, за контејнере којима је потребно много времена да се лансирају, тешко је добити ажурни статус: они су или „убијени“ пре него што заиста почну да функционишу, или ће дуго завршити у ћорсокаку. Нова провера (омогућено преко функције капије тзв StartupProbeEnabled) поништава – или боље речено, одлаже – ефекат било које друге провере до тренутка када под заврши рад. Из тог разлога, ова карактеристика је првобитно названа под-стартуп ливенесс-пробе холдофф. За подове којима је потребно много времена да се покрену, можете испитати стање у релативно кратким временским интервалима.

Поред тога, побољшање за РунтимеЦласс је одмах доступно у бета статусу, додајући подршку за „хетерогене кластере“. Ц РунтимеЦласс Сцхедулинг Сада уопште није неопходно да сваки чвор има подршку за сваку РунтимеЦласс: за подове можете изабрати РунтимеЦласс без размишљања о топологији кластера. Раније, да би се то постигло – тако да подови заврше на чворовима са подршком за све што им је потребно – било је неопходно доделити одговарајућа правила за НодеСелецтор и толеранције. ИН Кеп Говори о примерима употребе и, наравно, детаљима имплементације.

Мрежа

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

подршка двоструки мрежни стек - ИПв4/ИПв6 - и његово одговарајуће „разумевање“ на нивоу подова, чворова, услуга. Укључује ИПв4-то-ИПв4 и ИПв6-то-ИПв6 интероперабилност између модула, од модула до екстерних услуга, референтне имплементације (у оквиру Бридге ЦНИ, ПТП ЦНИ и Хост-Лоцал ИПАМ додатака), као и обрнуто компатибилност са Кубернетес кластерима који раде Само ИПв4 или ИПв6. Детаљи имплементације су у Кеп.
Пример приказивања ИП адреса два типа (ИПв4 и ИПв6) на листи подова:
```
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#
```
Нови АПИ за крајњу тачку - ЕндпоинтСлице АПИ. Решава проблеме перформанси/скалабилности постојећег АПИ-ја крајње тачке који утичу на различите компоненте у контролној равни (аписервер, етцд, ендпоинтс-цонтроллер, кубе-проки). Нови АПИ ће бити додат у Дисцовери АПИ групу и моћи ће да опслужује десетине хиљада позадинских крајњих тачака на свакој услузи у кластеру који се састоји од хиљада чворова. Да бисте то урадили, свака услуга је мапирана на Н објеката EndpointSlice, од којих свака подразумевано нема више од 100 крајњих тачака (вредност се може конфигурисати). ЕндпоинтСлице АПИ ће такође пружити могућности за његов будући развој: подршку за више ИП адреса за сваки под, нова стања за крајње тачке (не само Ready и NotReady), динамичка подскупина за крајње тачке.

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

АПИ машинерије

Права „прекретница стабилизације“ је у области Кубернетес АПИ сервера и интеракције са њим. Ово се догодило у великој мери захваљујући превођење у стабилан статус оних којима није потребно посебно упознавање ЦустомРесоурцеДефинитионс (ЦРД), који имају бета статус од далеких дана Кубернетеса 1.7 (а ово је јун 2017!). Иста стабилизација је дошла и до повезаних карактеристика:

"подизвори" са /status и /scale за ЦустомРесоурцес;
конверзија верзије за ЦРД, засноване на екстерном веб-хуку;
недавно представљена (у К8с 1.15) подразумеване вредности (подразумевано) и аутоматско уклањање поља (орезивање) за ЦустомРесоурцес;
прилика користећи ОпенАПИ в3 шему за креирање и објављивање ОпенАПИ документације која се користи за валидацију ЦРД ресурса на страни сервера.

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

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

А једина значајна иновација у алфа верзији била је неуспех из SelfLink — посебан УРИ који представља наведени објекат и који је део ObjectMeta и ListMeta (тј. део било ког објекта у Кубернетесу). Зашто га напуштају? Мотивација на једноставан начин звуци као одсуство стварних (претражених) разлога да ово поље још увек постоји. Формалнији разлози су оптимизација перформанси (уклањањем непотребног поља) и поједностављење рада генеричког-аписервера, који је приморан да обрађује такво поље на посебан начин (ово је једино поље које се поставља непосредно испред објекта). је серијализован). Права застарелост (у бета верзији) SelfLink десиће се Кубернетес верзија 1.20, а финална - 1.21.

Складиштење података

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

по први пут (у алфа верзији) појавио се Подршка ЦСИ додатка за Виндовс радничке чворове: тренутни начин рада са складиштем такође ће заменити додатке у стаблу у Кубернетес језгру и ФлекВолуме додатке из Мицрософта засноване на Поверсхелл-у;

Шема за имплементацију ЦСИ додатака у Кубернетес за Виндовс
прилика промена величине ЦСИ волумена, уведен још у К8с 1.12, прерастао је у бета верзију;
Слична „промоција“ (из алфа у бета) је постигнута могућношћу коришћења ЦСИ за креирање локалних ефемерних волумена (ЦСИ Инлине Волуме Суппорт).

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

Планер

Две значајне промене у распореду (обе у алфа верзији):

EvenPodsSpreading - прилика користите подове уместо логичких апликационих јединица за „правичну расподелу“ оптерећења (као Деплоимент и РеплицаСет) и прилагођавање ове дистрибуције (као строги захтев или као меки услов, тј. приоритет). Ова функција ће проширити постојеће могућности дистрибуције планираних подова, тренутно ограничених опцијама PodAffinity и PodAntiAffinity, дајући администраторима бољу контролу у овом питању, што значи бољу високу доступност и оптимизовану потрошњу ресурса. Детаљи - ин Кеп.
Коришћење БестФит Полици в Функција приоритета РекуестедТоЦапацитиРатио током планирања махуна, што ће омогућити да се пријаве бин паковање („паковање у контејнере“) и за основне ресурсе (процесор, меморија) и за проширене (као што је ГПУ). За више детаља, погледајте Кеп.

Подови за планирање: пре употребе политике најбољег уклапања (директно преко подразумеваног планера) и уз њено коришћење (преко проширивача планера)

Поред тога, представљени могућност креирања сопствених додатака за планирање ван главног стабла Кубернетес развоја (ван стабла).

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

Такође можете приметити у издању Кубернетес 1.16 иницијатива за доносећи доступне метрике у пуном реду, тачније у складу са званичним прописима до К8с инструментације. Они се у великој мери ослањају на одговарајуће Прометејева документација. Недоследности су настале из различитих разлога (на пример, неке метрике су једноставно креиране пре него што су се појавила тренутна упутства), а програмери су одлучили да је време да све доведу до једног стандарда, „у складу са остатком Прометхеус екосистема“. Тренутна имплементација ове иницијативе је у алфа статусу, која ће у наредним верзијама Кубернетеса прогресивно бити промовисана у бета (1.17) и стабилну (1.18).

Поред тога, могу се приметити следеће промене:

Виндовс подршка за развој с изглед Кубеадм услужни програми за овај ОС (алфа верзија), прилика RunAsUserName за Виндовс контејнере (алфа верзија), побољшање Подршка за групно управљани услужни налог (гМСА) до бета верзије, подршка монтирање/прикачи за вСпхере волумене.
Рециклирано механизам компресије података у АПИ одговорима. Раније је у ове сврхе коришћен ХТТП филтер, који је наметнуо низ ограничења која су спречавала да буде подразумевано омогућен. „Транспарентна компресија захтева“ сада ради: слање клијената Accept-Encoding: gzip у заглављу добијају ГЗИП компримовани одговор ако његова величина прелази 128 КБ. Го клијенти аутоматски подржавају компресију (слање потребног заглавља), тако да ће одмах приметити смањење саобраћаја. (Можда ће бити потребне мале измене за друге језике.)
Постало је могуће скалирање ХПА од/на нула подова на основу спољних метрика. Ако скалирате на основу објеката/спољних метрика, онда када радна оптерећења мирују, можете аутоматски скалирати на 0 реплика да бисте уштедели ресурсе. Ова функција би требало да буде посебно корисна у случајевима када радници захтевају ГПУ ресурсе, а број различитих типова неактивних радника премашује број доступних ГПУ-ова.
Нови клијент - k8s.io/client-go/metadata.Client — за „генерализовани“ приступ објектима. Дизајниран је да лако преузме метаподатке (тј. пододељак metadata) из ресурса кластера и са њима врши сакупљање смећа и операције квотирања.
Направи Кубернетес Сада можете без застарелих („уграђених“ у стаблу) добављача облака (алфа верзија).
У услужни програм кубеадм додато експериментална (алфа верзија) могућност примене прилагођених закрпа током операција init, join и upgrade. Сазнајте више о томе како да користите заставу --experimental-kustomize, види у Кеп.
Нова крајња тачка за аписервер - readyz, - омогућава вам да извезете информације о његовој спремности. АПИ сервер такође сада има заставицу --maximum-startup-sequence-duration, што вам омогућава да регулишете његово поновно покретање.
Два функције за Азуре проглашен стабилним: подршка зоне доступности (Зоне доступности) и унакрсна група ресурса (РГ). Поред тога, Азуре је додао:
- подршка за аутентификацију ААД и АДФС;
- Анотација service.beta.kubernetes.io/azure-pip-name да наведете јавну ИП адресу балансера оптерећења;
- прилика настројки LoadBalancerName и LoadBalancerResourceGroup.
АВС сада има подршка за ЕБС на Виндовс и оптимизовано ЕЦ2 АПИ позиви DescribeInstances.
Кубеадм је сада независан мигрира ЦореДНС конфигурација приликом надоградње ЦореДНС верзије.
Бинарне датотеке итдд у одговарајућој Доцкер слици направљен ворлд-екецутабле, што вам омогућава да покренете ову слику без потребе за роот правима. Такође, слика о миграцији итд престао подршка за верзију етцд2.
В Цлустер Аутосцалер 1.16.0 прешао на коришћење дистролесс-а као основне слике, побољшане перформансе, додати нови провајдери облака (ДигиталОцеан, Магнум, Пацкет).
Ажурирања у коришћеном/зависном софтверу: Го 1.12.9, етцд 3.3.15, ЦореДНС 1.6.2.

ПС

Прочитајте и на нашем блогу:

Извор: ввв.хабр.цом

Кубернетес 1.16: преглед главних иновација