🥇Kubernetes 1.16: агляд асноўных навін

Сёння, у сераду, адбудзецца чарговы рэліз Kubernetes - 1.16. Па традыцыі, якая склалася для нашага блога, вось ужо ў юбілейны — дзесяты — раз мы расказваем пра найбольш значныя змены ў новай версіі.

Інфармацыя, выкарыстаная для падрыхтоўкі гэтага матэрыялу, узята з табліцы Kubernetes enhancements tracking, CHANGELOG-1.16 і суадносных issues, pull requests, а таксама Kubernetes Enhancement Proposals (KEP). Такім чынам, паехалі!

вузлы

Па-сапраўднаму вялікая колькасць прыкметных новаўвядзенняў (у статусе альфа-версіі) прадстаўлена на баку вузлоў K8s-кластэраў (Kubelet).

Па-першае, прадстаўлены так званыя «эфемерныя кантэйнеры» (Ephemeral Containers), закліканыя спрасціць працэсы адладкі ў pod'ах. Новы механізм дазваляе запускаць спецыяльныя кантэйнеры, якія стартуюць у прасторы імёнаў існуючых pod'ов і жывуць непрацяглы час. Іх прызначэнне - узаемадзеянне з іншымі pod'амі і кантэйнерамі ў мэтах вырашэння якіх-небудзь праблем і адладкі. Для гэтай магчымасці рэалізавана новая каманда kubectl debug, падобная па сваёй сутнасці з kubectl exec: толькі замест запуску працэсу ў кантэйнеры (як у выпадку exec) яна запускае кантэйнер у pod'е. Напрыклад, такая каманда падлучыць новы кантэйнер да pod'у:

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

Падрабязнасці аб эфемерных кантэйнерах (і прыклады іх выкарыстання) можна знайсці ў адпаведным KEP. Бягучая рэалізацыя (у K8s 1.16) - альфа-версія, а сярод крытэрыяў яе перакладу ў бэта-версію значыцца "тэставанне Ephemeral Containers API на працягу не менш за 2 рэлізаў [Kubernetes]".

NB: Па сваёй сутнасці і нават назве фіча нагадвае ўжо існуючую ўбудову. kubectl-debug, пра які мы ўжо пісалі. Мяркуецца, што са з'яўленнем эфемерных кантэйнераў развіццё асобнага знешняга плагіна спыніцца.

Іншая навіна PodOverhead - заклікана падаць механізм падліку накладных выдаткаў на pod'ы, якія могуць моцна адрознівацца ў залежнасці ад выкарыстоўванага выкананага асяроддзя (runtime). У якасці прыкладу аўтары гэтага KEP прыводзяць Kata Containers, якія патрабуюць запуску гасцявога ядра, агента kata, init-сістэмы і да т.п. Калі overhead становіцца такім вялікім, яго нельга ігнараваць, а значыць - патрабуецца спосаб улічваць яго для наступнага кватавання, планаванні і да т.п. Для яго рэалізацыі ў PodSpec дададзена поле Overhead *ResourceList (супастаўляецца з дадзенымі ў RuntimeClass, калі такі выкарыстоўваецца).

Яшчэ адно прыкметнае новаўвядзенне менеджэр тапалогіі вузла (Node Topology Manager), Закліканы уніфікаваць падыход да тонкай наладзе размеркавання апаратных рэсурсаў для розных кампанентаў у Kubernetes. Гэтая ініцыятыва выклікана якая расце запатрабаваннем розных сучасных сістэм (з вобласці тэлекамунікацый, машыннага навучання, фінансавых паслуг і да т.п.) у высокапрадукцыйных паралельных вылічэннях і мінімізацыі затрымак пры выкананні аперацый, для чаго яны выкарыстоўваюць прасунутыя магчымасці CPU і апаратнага паскарэння. Такія аптымізацыі ў Kubernetes да гэтага часу дасягаліся дзякуючы разрозненым кампанентам (CPU manager, Device manager, CNI), а зараз ім дададуць адзіны ўнутраны інтэрфейс, які уніфікуе падыход і спросціць падключэнне новых аналагічных – так званых topology-aware – кампанентаў на баку Kubelet. Падрабязнасці - у адпаведным KEP.

Схема кампанентаў Topology Manager

Наступная фіча - праверка кантэйнераў падчас іх запуску (startup probe). Як вядома, для кантэйнераў, што доўга запускаюцца, цяжка атрымаць актуальны статут: іх альбо "забіваюць" яшчэ да рэальнага пачатку функцыянавання, альбо яны на доўгі час трапляюць у deadlock. Новая праверка (уключаецца праз feature gate пад назвай StartupProbeEnabled) адмяняе - дакладней, адкладае - дзеянне любых іншых праверак да таго моманту, калі pod скончыў свой запуск. Па гэтай прычыне фічу першапачаткова называлі pod-startup liveness-probe holdoff. Для pod'ов, што доўга стартуюць, можна праводзіць апытанне стану ў адносна кароткія часавыя інтэрвалы.

Акрамя таго, адразу ў статуце бэта-версіі прадстаўлена паляпшэнне для RuntimeClass, якое дадае падтрымку «гетэрагенных кластараў». C RuntimeClass Scheduling зараз зусім не абавязкова кожнаму вузлу мець падтрымку кожнага RuntimeClass'а: для pod'ов можна выбіраць RuntimeClass, не думаючы аб тапалогіі кластара. Раней для дасягнення гэтага каб pod'ы апыняліся на вузлах з падтрымкай усяго ім патрэбнага даводзілася прызначаць адпаведныя правілы да NodeSelector і tolerations. У КЭП расказваецца аб прыкладах выкарыстання і, вядома ж, падрабязнасцях рэалізацыі.

сетка

Дзве значныя сеткавыя фічы, што з'явіліся ўпершыню (у альфа-версіі) у Kubernetes 1.16 – гэта:

Падтрымка падвойнага сеткавага стэка - IPv4/IPv6 - І адпаведнае яго "разуменне" на ўзроўні pod'аў, вузлоў, сэрвісаў. Яна ўключае ў сябе ўзаемадзеянне IPv4-to-IPv4 і IPv6-to-IPv6 паміж pod'амі, з pod'аў у знешнія сэрвісы, эталонныя рэалізацыі (у рамках плагінаў Bridge CNI, PTP CNI і Host-Local IPAM), а таксама зваротную сумяшчальнасць з кластарамі Kubernetes, якія працуюць толькі па IPv4 ці IPv6. Падрабязнасці рэалізацыі - у КЭП.
Прыклад вываду IP-адрасоў двух відаў (IPv4 і IPv6) у спісе pod'аў:
```
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 з прадукцыйнасцю/маштабаванасцю, што закранаюць розныя кампаненты ў control-plane (apiserver, etcd, endpoints-controller, kube-proxy). Новы API будзе дададзены ў API-групу Discovery і зможа абслугоўваць дзясяткі тысяч backend endpoint'аў на кожным сэрвісе ў кластары, які складаецца з тысячай вузлоў. Для гэтага кожны Service адлюстроўваецца ў N аб'ектаў EndpointSlice, кожны з якіх па змаўчанні мае не больш за 100 endpoint'аў (значэнне наладжваецца). У EndpointSlice API прадугледзяць і магчымасці для яго будучага развіцця: падтрымкі мноства IP-адрасоў у кожнага pod'а, новых станаў для endpoint'аў (не толькі Ready и NotReady), дынамічнага subsetting для endpoint'аў.

Да бэта-версіі прасунуўся прадстаўлены ў мінулым рэлізе finalizer, названы service.kubernetes.io/load-balancer-cleanup і які прымацоўваецца да кожнага сэрвісу з тыпам LoadBalancer. У момант выдалення такога сэрвісу ён прадухіляе фактычнае выдаленне рэсурсу, пакуль не завершана "зачыстка" усіх адпаведных рэсурсаў балансавальніка.

API Machinery

Сапраўдная "вяха стабілізацыі" зафіксаваная ў вобласці API-сервера Kubernetes і ўзаемадзеянні з ім. Шмат у чым гэта адбылося дзякуючы пераводу ў статус stable якія не маюць патрэбы ў асаблівым прадстаўленні CustomResourceDefinitions (CRD), што мелі статус бэта-версіі з часоў далёкага Kubernetes 1.7 (а гэта чэрвень 2017!). Такая ж стабілізацыя прыйшла і да звязаных з імі фічоў:

«падрэсурсы» (subresources) са /status и /scale для CustomResources;
пераўтварэнне версій для CRD, заснаванае на вонкавым webhook'е;
прадстаўленыя нядаўна (у K8s 1.15) значэнні па змаўчанні (defaulting) і аўтаматычнае выдаленне палёў (pruning) для CustomResources;
магчымасць ужыванні схемы OpenAPI v3 для стварэння і публікацыі OpenAPI-дакументацыі, выкарыстоўванай для валідацыі CRD-рэсурсаў на боку сервера.

Яшчэ адзін механізм, які даўно стаў звыклым для адміністратараў Kubernetes: admission webhook - таксама доўгі час знаходзіўся ў статусе бэты (з K8s 1.9) і зараз абвешчаны стабільным.

Дзве іншыя фічы дасягнулі бэта-версіі: server-side apply и watch bookmarks.

А адзіным значным новаўвядзеннем у альфа-версіі стаў адмова ад SelfLink - спецыяльнага URI, які прадстаўляе названы аб'ект і які з'яўляецца часткай ObjectMeta и ListMeta (г.зн. часткай любога аб'екта ў Kubernetes). Навошта ад яго адмаўляюцца? Матывацыя "па-простаму" гучыць як адсутнасць сапраўдных (непераадольных) прычын для таго, каб гэтае поле па-ранейшаму існавала. Больш фармальныя чыннікі – аптымізаваць прадукцыйнасць (прыбраўшы непатрэбнае поле) і спрасціць працу generic-apiserver, які змушаны апрацоўваць такое поле адмысловай выявай (гэта адзінае поле, якое ўсталёўваецца прама перад серыялізацыяй аб'екта). Сапраўднае "састарванне" (у рамках бэта-версіі) SelfLink адбудзецца да версіі Kubernetes 1.20, а канчатковае - 1.21.

Захоўванне дадзеных

Асноўная праца ў вобласці storage, як і ў мінулых рэлізах, назіраецца ў вобласці падтрымкі CSI. Галоўнымі зменамі тут сталі:

упершыню (у альфа-версіі) з'явілася падтрымка CSI-плагінаў для працоўных вузлоў з Windows: актуальны спосаб працы са сховішчамі і тут прыйдзе на змену убудовам in-tree у ядры Kubernetes і FlexVolume-убудовам ад Microsoft на базе Powershell;

Схема рэалізацыі CSI-плагінаў у Kubernetes для Windows
магчымасць змены памеру CSI-томаў, прадстаўленая яшчэ ў K8s 1.12, дарасла да бэта-версіі;
аналагічнага "падвышэння" (з альфа- да бэта-версіі) дасягнула магчымасць выкарыстання CSI для стварэння лакальных эфемерных тамоў (CSI Inline Volume Support).

Якая з'явілася ў мінулай версіі Kubernetes функцыя кланавання тамоў (выкарыстанне існуючых PVC у якасці DataSource для стварэння новых PVC) таксама зараз атрымала статут бэта-версіі.

Планавальнік

Дзве прыкметныя змены ў планаванні (абодва ў альфа-версіі):

EvenPodsSpreading - магчымасць выкарыстоўваць для «сумленнага размеркавання» нагрузак pod'ы замест лагічных адзінак прыкладання (накшталт Deployment і ReplicaSet) і рэгуляванні гэтага размеркавання (як цвёрдага патрабавання або як мяккай умовы, г.зн. прыярытэту). Фіча пашырыць існуючыя магчымасці размеркавання запланаваных pod'ов, цяпер абмежаваныя опцыямі. PodAffinity и PodAntiAffinity, даўшы адміністратарам больш тонкі кантроль у гэтым пытанні, а значыць - лепшую высокую даступнасць і аптымізаванае спажыванне рэсурсаў. Падрабязнасці - у КЭП.
Выкарыстанне BestFit Policy в RequestedToCapacityRatio Priority Function падчас планавання pod'ов, што дазволіць ўжываць кантэйнерная ўпакоўка («упакаванне ў кантэйнеры») як для асноўных рэсурсаў (працэсар, памяць), так і пашыраных (накшталт GPU). Больш падрабязна гл. у КЭП.

Планаванне pod'ов: да выкарыстання best fit policy (наўпрост праз default scheduler) і з яе выкарыстаннем (праз scheduler extender)

Акрамя таго, прадстаўлена магчымасць ствараць свае плагіны для планавальніка па-за асноўным дрэвам распрацоўкі Kubernetes (out-of-tree).

іншыя змены

Таксама ў рэлізе Kubernetes 1.16 можна адзначыць ініцыятыву па прывядзенні наяўных метрык у поўны парадак, а калі дакладней - у адпаведнасць з афіцыйнымі прадпісаннямі да інструментацыі K8s. Яны па вялікім рахунку абапіраюцца на адпаведную дакументацыю Prometheus. Несыстакоўкі ж утварыліся па розных прычынах (напрыклад, некаторыя метрыкі былі папросту створаны яшчэ да таго, як бягучыя інструкцыі з'явіліся), і распрацоўшчыкі вырашылі, што настаў час прывесці ўсё да адзінага стандарту, "у адпаведнасць з астатняй экасістэмай Prometheus". Бягучая рэалізацыя гэтай ініцыятывы носіць статут альфа-версіі, які будзе паслядоўна павялічвацца ў наступных версіях Kubernetes да бэты (1.17) і стабільнага (1.18).

Акрамя таго, можна адзначыць наступныя змены:

Развіццё падтрымкі Windows с з'яўленнем утыліты Kubeadm для гэтай АС (альфа-версія), магчымасцю RunAsUserName для Windows-кантэйнераў (альфа-версія), паляпшэннем падтрымкі Group Managed Service Account (gMSA) да бэта-версіі, падтрымкай mount/attach для тамоў vSphere.
Перапрацаваны механізм сціску дадзеных у адказах API. Раней для гэтых мэт выкарыстоўваўся HTTP-фільтр, які накладваў шэраг абмежаванняў, якія перашкаджаюць яго ўключэнню па змаўчанні. Цяпер працуе «празрысты сціск запытаў»: кліенты, якія адпраўляюць Accept-Encoding: gzip у загалоўку, атрымліваюць сціснуты ў GZIP адказ, калі яго памер перавышаў 128 Кб. Кліенты на Go аўтаматычна падтрымліваюць сціск (адпраўляюць патрэбны загаловак), так што адразу заўважаць зніжэнне трафіку. (Для іншых моў могуць потебоваться невялікія мадыфікацыі.)
Стала магчымым маштабаванне HPA з/да нуля pod'ов на аснове вонкавых метрык. Калі маштабаванне вырабляецца на аснове аб'ектаў/вонкавых метрык, то калі працоўныя нагрузкі прастойваюць, можна аўтаматычна маштабавацца да 0 рэплік, каб зэканоміць рэсурсы. Асабліва карыснай гэтая фіча павінна апынуцца для выпадкаў, калі worker'ы запытваюць рэсурсы GPU, а колькасць розных тыпаў прастойваюць worker'аў перавышае лік даступных GPU.
Новы кліент - k8s.io/client-go/metadata.Client - Для "абагульненага" доступу да аб'ектаў. Ён прызначаны для таго, каб лёгка атрымліваць метададзеныя (г.зн. падраздзел metadata) з рэсурсаў кластара і ажыццяўляць з імі аперацыі з разраду збору смецця і кватавання.
Збіраць Kubernetes зараз можна без састарэлых («убудаваных» у in-tree) хмарных правайдэраў (альфа-версія).
Ва ўтыліту kubeadm дадалі эксперыментальную (альфа-версія) магчымасць ужываць патчы kustomize падчас аперацый init, join и upgrade. Падрабязней аб тым, як карыстацца сцягам --experimental-kustomize, гл. у КЭП.
Новы endpoint для apiserver readyz, - Які дазваляе экспартаваць інфармацыю аб яго гатоўнасці (readiness). Таксама ў API-сервера з'явіўся сцяг. --maximum-startup-sequence-duration, які дазваляе рэгуляваць яго перазапускі.
два фічы для Azure абвешчаныя стабільнымі: падтрымка зон даступнасці (Availability Zones) і cross resource group (RG). Акрамя таго, у Azure дададзены:
- падтрымка аўтэнтыфікацыі AAD і ADFS;
- анатацыя service.beta.kubernetes.io/azure-pip-name для ўказання публічнага IP у балансавальніка нагрузкі;
- магчымасць налады LoadBalancerName и LoadBalancerResourceGroup.
У AWS з'явілася падтрымка для EBS у Windows і аптымізаваны API-выклікі EC2 DescribeInstances.
Kubeadm зараз самастойна мігруе канфігурацыю CoreDNS пры абнаўленні версіі CoreDNS.
Бінарнікі і г.д. у адпаведным Docker-ладзе зрабілі world-executable, што дазваляе запускаць гэтую выяву без неабходнасці ў правах root. Акрамя таго, выява міграцыі etcd спыніў падтрымку версіі etcd2.
В Cluster Autoscaler 1.16.0 перайшлі на выкарыстанне distroless у якасці базавай выявы, палепшылі прадукцыйнасць, дадалі новых хмарных правайдэраў (DigitalOcean, Magnum, Packet).
Абнаўленні ў выкарыстаным/залежным праграмным забеспячэнні: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

Чытайце таксама ў нашым блогу:

Крыніца: habr.com

Kubernetes 1.16: агляд асноўных навін