🥇Kubernetes 1.17: преглед на основните нововъведения

Вчера, 9 декември, се състоя другият релиз на Kubernetes — 1.17. По утвърдена традиция за нашия блог, ние разказваме за най-значителните промени в новата версия.

Kubernetes 1.17: обзор на основните нововъведения

Информацията, използвана за подготовката на този материал, е взета от официалното съобщение, таблица за проследяване на подобренията в Kubernetes, CHANGELOG-1.17 и съответните проблеми, pull requests, а също така Kubernetes Enhancement Proposals (KEP). И така, какво ново?..

Маршрутизиране с оглед на топологията

От дълго време в общността на Kubernetes чакат тази функция — Topology-aware service routing. Ако KEP която започна през октомври 2018-та, а официалното подобрение е - 2 години назад, а обикновените проблеми (като например този) и изобщо по-стари с още няколко години…

Основната идея е да се предостави възможност за реализиране на "локално" маршрутизиране за услуги, разположени в 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 (в същото време сега изискват за хоста да добавят и IPv6 адрес); е добавена поддръжка на два стека в /etc/hosts KIND
(Kubernetes IN Docker) и обновени e2e тестове. (Kubernetes IN Docker) и kubeadm;
обновени e2e тестове.

Kubernetes 1.17: обзор на основните нововъведения
Илюстрация използване на двойния стек 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). Прогнозите за другите хранилища са:

Kubernetes 1.17: обзор на основните нововъведения

За това как „традиционната“ поддръжка на хранилища в K8s е достигнала до CSI, разказахме в тази статия. А преминаването на миграцията CSI в статус бета версия е посветена на отделна публикация в блога на проекта.

Освен това статусът на бета версия (т.е. включване по подразбиране) в изданието Kubernetes 1.17 достигна и друга значима функционалност в контекста на CSI, която има своето начало (алфа реализация) в K8s 1.12, — създаване на моментни снимки и възстановяване от тях. Сред промените, направени в Kubernetes Volume Snapshot по пътя към бета изданието:

разделяне на sidecar-а CSI external-snapshotter на два контролера,
добавен секрет за изтриване (deletion secret) като анотация към съдържанието на моментната снимка на тома,
нов финализатор (finalizer) за предотвратяване на изтриването на API обекта на моментната снимка при наличие на оставащи връзки.

Към момента на изданието 1.17 функцията се поддържа от три 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

В alpha версия за първи път представено структурирано изходно представяне за утилитата kubeadm. Поддържани формати: JSON, YAML, Go шаблон.

Мотивацията за реализиране на тази функция (според KEP) е следната:

Въпреки че 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 в специализирания Lease API;
«защита на финализатора» (Защита на финализатор) за балансировачи на натоварване (проверка на съответстващите ресурси на Service преди изтриване на ресурсите на LoadBalancer);
оптимизация на kube-apiserver в производителността при работа с множество watches, наблюдаващи идентични набори от обекти, — постигната чрез избягване на повторна сериализация на същите обекти за всеки watcher.

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

Пълен списък с нововъведения в Kubernetes 1.17, разбира се, не се ограничава само до изброените по-горе. Ето и някои други (за по-пълен списък — вижте CHANGELOG):

до бета-версия «достигната» представената в миналия релиз функция 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.

P.S.

Прочетете също в нашия блог:

Източник: habr.com