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

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

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

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

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

В обществото на Kubernetes дълго време чакат тази функция — Службена маршрутизация с познание за топологията. Ако 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 (Kubernetes IN Docker) и
обновени e2e тестове. KIND (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 версия структурирано извеждане за инструментa kubeadm. Поддържаните формати са: JSON, YAML, Go-шаблон.

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

Въпреки че Kubernetes може да бъде инсталиран ръчно, стандартът де фаacto (ако не и де юре) за тази операция е използването на kubeadm. Популярни инструменти за управление на системи като Terraform се опират на kubeadm за разгръщане на Kubernetes. Планираните подобрения в Cluster API включват компонируем пакет за стартиране на 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": "Стандартният токен за стартиране, генериран от '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) за Customized Resources;
споделени между контейнери в pod’а namespace на процесите;
ScheduleDaemonSetPods — планиране на pod’ове в DaemonSet чрез kube-scheduler (вместо контролера DaemonSet);
динамични лимити на брой томове в зависимост от типа на възела;
поддръжка на променливи среди за имената на директории, монтирани като subPath;
пренасяне на Kubelet heartbeats в специализиран Lease API;
«защита на финализатора» (Защита на финализатора) за балансировчици на натоварването (проверка на съответните ресурси на Service преди изтриване на ресурсите на LoadBalancer);
оптимизация на kube-apiserver в производителността при работа с множество наблюдения, следящи идентични набори от обекти, — постига се чрез избягване на повторна сериализация на едни и същи обекти за всеки наблюдател.

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

Пълният списък с нововъведения в 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 сега стартират с по-малки привилегии;
хиперкюб отделен в 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