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

Учора, 9 снежня, адбыўся чарговы рэліз Kubernetes - 1.17. Па традыцыі, якая склалася для нашага блога, мы расказваем пра найбольш значныя змены ў новай версіі.

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

Маршрутызацыя з улікам тапалогіі

Вось ужо доўгі час у супольнасці Kubernetes чакалі гэтай фічы. Topology-aware service routing. Калі КЭП па ёй бярэ свой пачатак у кастрычніку 2018-га, а афіцыйны ўзмацненне - 2 гады таму, то звычайныя issues (накшталт гэтага) — і зусім старэйшыя яшчэ на некалькі гадоў…

Агульная ідэя зводзіцца да таго, каб даць магчымасць рэалізоўваць "лакальную" маршрутызацыю для сэрвісаў, якія знаходзяцца ў Kubernetes. «Лакальнасць» у дадзеным выпадку азначае «той жа самы тапалагічны ўзровень» (topology level), якім можа з'яўляцца:

аднолькавы для сэрвісаў вузел,
тая ж самая серверная стойка,
той жа самы рэгіён,
той жа самы хмарны правайдэр,
...

Прыклады выкарыстання такой фічы:

эканомія на трафіку ў хмарных усталёўках са мноствам зон даступнасці (multi-AZ) - гл. свежую ілюстрацыю на прыкладзе трафіку аднаго рэгіёна, але розных AZ у AWS;
меншыя затрымкі ў прадукцыйнасці/лепшая прапускная здольнасць;
шардыраваны сэрвіс, які мае лакальную інфармацыю аб вузле ў кожным шардзе;
размяшчэнне fluentd (або аналагаў) на адзін вузел з праграмамі, логі якіх збіраюцца;
...

Такую маршрутызацыю, «дасведчаную» аб тапалогіі, яшчэ завуць падабенствам network affinity – па аналогіі з node affinity, pod affinity/anti-affinity або якія з'явіліся не так даўно Topology-Aware Volume Scheduling (і Volume Provisioning). Бягучы ўзровень рэалізацыі ServiceTopology у Kubernetes - альфа-версія.

Падрабязнасці аб тым, як фіча ўладкована і як ёй ужо можна скарыстацца, чытайце ў гэтым артыкуле ад аднаго з аўтараў.

Падтрымка падвойнага стэка IPv4/IPv6

Значны прагрэс зафіксаваны у іншай сеткавай фічы: адначасовай падтрымцы двух IP-стэкаў, што была ўпершыню прадстаўлена ў K8s 1.16. У прыватнасці, новы рэліз прынёс наступныя змены:

у kube-proxy рэалізавана магчымасць адначасовай працы ў абодвух рэжымах (IPv4 і IPv6);
в Pod.Status.PodIPs з'явілася падтрымка downward API (адначасова з гэтым у /etc/hosts зараз патрабуюць для хаста дадаваць і IPv6-адрас);
падтрымка двух стэкаў у вЫГЛЯД (Kubernetes IN Docker) і кубеадм;
абноўленыя e2e-тэсты.

ілюстрацыя выкарыстання падвойнага стэка IPV4/IPv6 у KIND

Прагрэс па CSI

Аб'яўлена стабільнай падтрымка тапалогій для сховішчаў на базе CSI, упершыню прадстаўленая ў K8s 1.12.

Ініцыятыва па міграцыі плагінаў тамоў на CSI - CSI Migration - дасягнула бэта-версіі. Гэтая фіча крытычная для таго, каб перавесці існуючыя плагіны сховішчаў. (in-tree) на сучасны інтэрфейс (CSI, out-of-tree) неўзаметку для канчатковых карыстальнікаў Kubernetes. Адміністратарам кластараў будзе дастаткова актываваць CSI Migration, пасля чаго існуючыя stateful-рэсурсы і працоўныя нагрузкі будуць па-ранейшаму "проста працаваць"… але ўжо з выкарыстаннем актуальных CSI-драйвераў замест састарэлых, якія ўваходзяць у ядро Kubernetes.

На дадзены момант у статуце бэта-версіі гатова міграцыя для драйвераў AWS EBS (kubernetes.io/aws-ebs) і GCE PD (kubernetes.io/gce-pd). Прагнозы па іншых сховішчах такія:

Аб тым, як "традыцыйная" падтрымка сховішчаў у K8s прыйшла да CSI, мы распавядалі ў гэтым артыкуле. А пераходу міграцыі CSI у статут бэта-версіі прысвечана асобная публікацыя у блогу праекта.

Акрамя таго, статуту бэта-версіі (т.е. уключэнні па змаўчанні) у рэлізе Kubernetes 1.17 дасягнула іншая значная функцыянальнасць у кантэксце CSI, якая бярэ свой пачатак (альфа-рэалізацыю) у K8s 1.12, — стварэнне снапшотаў і аднаўленне з іх. Сярод змен, зробленых у Kubernetes Volume Snapshot на шляху да бэта-рэлізу:

разбіўка sidecar'а CSI external-snapshotter на два кантролера,
дададзены сакрэт на выдаленне (deletion secret) як анатацыя да змесціва снапшота тома,
новы фіналізатар (finalizer) для прадухілення выдалення API-аб'екта снапшота пры наяўнасці пакінутых сувязяў.

На момант рэлізу 1.17/XNUMX фіча падтрымліваецца ў трох CSI-драйвераў: GCE Persistent Disk CSI Driver, Portworx CSI Driver і NetApp Trident CSI Driver. Падрабязней пра яе рэалізацыю і выкарыстанне можна прачытаць у гэтай публікацыі у блогу.

Cloud Provider Labels

Лэйблы, якія аўтаматычна прызначаюцца на ствараныя вузлы і тамы ў залежнасці ад выкарыстоўванага хмарнага правайдэра., былі даступныя ў Kubernetes як бэта-версія ўжо вельмі даўно – пачынаючы з рэлізу K8s 1.2 (красавік 2016 года!). Улічваючы іх шырокае прымяненне так доўга, распрацоўшчыкі вырашылі, Што надышоў час аб'явіць фічу стабільнай (GA).

Таму ўсе яны былі перайменаваны адпаведным чынам (па тапалогіях):

beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

… але па-ранейшаму даступныя і па сваіх старых назвах (для зваротнай сумяшчальнасці). Зрэшты, усім адміністратарам рэкамендуецца пераходзіць на актуальныя лэйблы. Адпаведная дакументацыя K8s была абноўлена.

Структураваная выснова kubeadm

У фармаце альфа-версіі ўпершыню прадстаўлены структураваная выснова для ўтыліты kubeadm. Падтрымліваюцца фарматы: JSON, YAML, Go-шаблон.

Матывацыя да рэалізацыі гэтай фічы (згодна КЭП) такая:

Хоць Kubernetes і можа быць разгорнуты ўручную, стандартам дэ-факта (калі не дэ-юрэ) для гэтай аперацыі з'яўляецца выкарыстанне kubeadm. Папулярныя прылады кіравання сістэмамі накшталт Terraform абапіраюцца на kubeadm для дэплою Kubernetes. Запланаваныя паляпшэнні ў Cluster API складаюцца з кампанаваны пакет для bootstrapping'а Kubernetes з kubeadm і cloud-init.

Без структураванай высновы нават самыя бяскрыўдныя на першы погляд змены могуць зламаць Terraform, Cluster API і іншы софт, які выкарыстоўвае вынікі працы kubeadm.

У бліжэйшых планах значыцца падтрымка (у выглядзе структураванай высновы) для наступных каманд kubeadm:

alpha certs
config images list
init
token create
token list
upgrade plan
version

Ілюстрацыя JSON-адказу на каманду kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

Стабілізацыя іншых навін

Наогул жа, рэліз Kubernetes 1.17 адбыўся пад дэвізам.стабільнасць». Таму спрыяў той факт, што вельмі многія фічы ў ім (іх агульная колькасць - 14) атрымалі статус GA. Сярод такіх:

«пазнака» вузлоў па пэўных умовах (TaintNodesByCondition), якая з'явілася ў K8s 1.8;
Watch Bookmarks - новы тып падзей, якія маюць пазнаку, што ўсе аб'екты да пэўнай версіі (resourceVersion) ужо былі апрацаваны watch'ем;
значэння па змаўчанні (defaulting) для Custom Resources;
падзяляныя паміж кантэйнерамі у pod'е process namespaces;
ScheduleDaemonSetPods - планаванне pod'аў у DaemonSet з дапамогай kube-scheduler (замест кантролера DaemonSet);
дынамічныя ліміты на колькасць тамоў у залежнасці ад тыпу вузла;
падтрымка зменных асяроддзя для назваў дырэкторый, якія мантуюцца як subPath;
перанос Kubelet heartbeats у спецыялізаваны Lease API;
"абарона фіналізатара" (Finalizer Protection) для балансавальнікаў нагрузкі (праверка адпаведных рэсурсаў Service'а перад выдаленнем рэсурсаў LoadBalancer'а);
аптымізацыя kube-apiserver у прадукцыйнасці пры працы са мноствам watches, якія назіраюць за ідэнтычнымі наборамі аб'ектаў, - дасягаецца дзякуючы пазбягаю паўторнай серыялізацыі адных і тых жа аб'ектаў для кожнага watcher'а.

Іншыя змены

Поўны спіс навін у Kubernetes 1.17, вядома, не абмяжоўваецца пералічанымі вышэй. Вось некаторыя іншыя з іх (а для больш поўнага пераліку - гл. ЗМЯНЕННЕ):

да бэта-версіі «даросла» прадстаўленая ў мінулым рэлізе фіча RunAsUserName для Windows;
аналагічная змена спасцігла EndpointSlice API (таксама з K8s 1.16), аднак пакуль гэтае рашэнне для паляпшэння прадукцыйнасці/маштабаванасці Endpoint API не актываванае па змаўчанні;
крытычныя для працы кластара pod'ы цяпер могуць быць створаны не толькі ў прастор імёнаў kube-system (падрабязнасці гл у дакументацыі па Limit Priority Class consumption);
новая опцыя для kubelet --reserved-cpus - дазваляе відавочна вызначаць спіс CPU, зарэзерваваных для сістэмы;
для kubectl logs прадстаўлены новы сцяг --prefix, які дадае назву pod'а і кантэйнера крыніцы да кожнага радка лога;
в label.Selector дадалі RequiresExactMatch;
усе кантэйнеры ў kube-dns зараз запускаюцца з меншымі прывілеямі;
hyperkube выдзелены ў асобны GitHub-рэпазітар і больш не будзе ўключацца ў рэлізы Kubernetes;
значна палепшана прадукцыйнасць kube-proxy для не-UDP-партоў.

Змены ў залежнасцях:

версія CoreDNS у складзе ў kubeadm – 1.6.5;
версія crictl абноўлена да v1.16.1;
CSI 1.2.0;
etcd 3.4.3;
апошняя правераная версія Docker падвышаная да 19.03;
мінімальная версія Go, патрабаваная для зборкі Kubernetes 1.17, - 1.13.4.

PS

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

Крыніца: habr.com

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