Kubernetes 1.17: Акценти от новите неща

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

Информацията, използвана за подготовката на този материал, е взета от официалното съобщение, Таблици за проследяване на подобрения на Kubernetes, ПРОМЕНИ-1.17 и свързани проблеми, заявки за изтегляне и предложения за подобряване на Kubernetes (KEP). Е какво ново?..

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

Общността на Kubernetes чакаше тази функция от дълго време - Маршрутизиране на услуги, съобразено с топологията, ако КЕП произхожда от октомври 2018 г. и официалният повишаване — Преди 2 години, обичайните проблеми (като то) - и още няколко години по-стар...

Общата идея е да се осигури възможност за прилагане на „локално“ маршрутизиране за услуги, намиращи се в Kubernetes. „Местност“ в този случай означава „същото топологично ниво“ (ниво на топология), което може да бъде:

• идентичен възел за услуги,
• същата сървърна стойка,
• същия регион
• същия доставчик на облак,
• ...

Примери за използване на тази функция:

• спестяване на трафик в облачни инсталации с множество зони на достъпност (multi-AZ) - вижте. свежа илюстрация използвайки примера за трафик от един и същи регион, но различни AZ в AWS;
• по-ниска латентност на производителността/по-добра производителност;
• шардирана услуга, която има локална информация за възела във всеки шард;
• поставяне на fluentd (или аналози) на същия възел с приложенията, чиито журнали се събират;
• ...

Такова маршрутизиране, което "знае" за топологията, се нарича още мрежов афинитет - по аналогия с възлов афинитет, шушулка афинитет/анти-афинитет или се появи не толкова отдавна Планиране на томове, съобразено с топологията (И Предоставяне на обем). Текущо ниво на изпълнение ServiceTopology в Kubernetes - алфа версия.

За подробности как работи функцията и как вече можете да я използвате, прочетете тази статия от един от авторите.

Поддръжка на двоен стек на IPv4/IPv6

Значителен напредък фиксирани в друга мрежова функция: едновременна поддръжка на два IP стека, която беше въведена за първи път през K8s 1.16. По-специално, новата версия донесе следните промени:

• в kube-прокси изпълнени възможност за едновременна работа в двата режима (IPv4 и IPv6);
• в Pod.Status.PodIPs се появи поддръжка за API надолу (по същото време, както в /etc/hosts сега те изискват от хоста да добави IPv6 адрес);
• поддръжка на двоен стек МИЛ (Kubernetes IN Docker) и kubeadm;
• актуализирани e2e тестове.

илюстрация използвайки двоен стек IPV4/IPv6 в KIND

Напредък по CSI

Обявен за стабилен поддръжка на топология за базирано на CSI съхранение, въведено за първи път през K8s 1.12.

Инициатива за мигриране на плъгини за обем към CSI - CSI миграция - достигна бета версия. Тази функция е от решаващо значение за превода на съществуващи добавки за съхранение (в дърво) към модерен интерфейс (CSI, извън дървото) невидими за крайните потребители на Kubernetes. Клъстерните администратори ще трябва само да активират CSI Migration, след което съществуващите ресурси и работни натоварвания ще продължат да „просто работят“... но с помощта на най-новите CSI драйвери вместо остарелите, включени в ядрото на Kubernetes.

В момента миграцията за AWS EBS драйвери е готова в бета версия (kubernetes.io/aws-ebs) и GCE PD (kubernetes.io/gce-pd). Прогнозите за други складови съоръжения са както следва:

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

В допълнение, друга важна функционалност в контекста на CSI, която произхожда (алфа реализация) в K1.17s 8, достигна бета статус (т.е. активирана по подразбиране) в изданието Kubernetes 1.12 - създаване на моментни снимки и възстановяване от тях. Сред промените, направени в Kubernetes Volume Snapshot по пътя към бета версия:

• разделяне на страничната количка CSI с външна снимка на два контролера,
• добавена тайна за изтриване (тайна за изтриване) като анотация към съдържанието на моментна снимка на том,
• нов финализатор (финализатор) за да предотвратите изтриването на обекта на API за моментна снимка, ако има оставащи връзки.

По време на версия 1.17 функцията се поддържа от три CSI драйвера: GCE Persistent Disk CSI Driver, Portworx CSI Driver и NetApp Trident CSI Driver. Повече подробности за прилагането и използването му можете да намерите в тази публикация в блога.

Етикети на облачен доставчик

Етикетира това автоматично присвоени на създадени възли и томове в зависимост от използвания облачен доставчик, са налични в 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 template.

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

Въпреки че Kubernetes може да се внедри ръчно, де факто (ако не де юре) стандартът за тази операция е да се използва kubeadm. Популярни инструменти за управление на системи като Terraform разчитат на kubeadm за внедряване на Kubernetes. Планираните подобрения на 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": "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;
• Гледайте отметки - нов тип събития, които имат етикет, че всички обекти са до определена версия (resourceVersion) вече са обработени от часовник;
• стойности по подразбиране (по подразбиране) за персонализирани ресурси;
• споделени между контейнери в пространствата от имена на процеса на pod;
• ScheduleDaemonSetPods - подове за планиране в DaemonSet използване на kube-scheduler (вместо контролера DaemonSet);
• динамични граници върху броя на томовете в зависимост от типа възел;
• поддръжка на променливи на средата за имена на директории, монтирани като subPath;
• Прехвърляне на сърдечни удари на Kubelet към специализиран API за лизинг;
• "защита на финализатора" (Защита на финализатора) за балансьори на натоварване (проверка на съответните ресурси на услугата преди изтриване на ресурсите на LoadBalancer);
• оптимизация на kube-apiserver в производителност при работа с множество часовници, наблюдаващи идентични набори от обекти - постигнато чрез избягване на повтаряща се сериализация на едни и същи обекти за всеки наблюдател.

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

Пълният списък с иновации в Kubernetes 1.17, разбира се, не се ограничава до изброените по-горе. Ето някои други (а за по-пълен списък вижте ЧАНГЕЛОГ):

• Функцията, представена в последната версия, достигна бета версия RunAsUserName за прозорци;
• подобна промяна сполетя EndpointSlice API (също от K8s 1.16), но засега това решение за подобряване на производителността/мащабируемостта на Endpoint API не е активирано по подразбиране;
• pods вече са критични за работата на клъстера може да се създаде не само в пространствата от имена kube-system (за подробности вижте документацията за Ограничете консумацията на приоритетен клас);
• нова опция за kubelet - --reserved-cpus — ви позволява изрично да дефинирате списъка с централни процесори, запазени за системата;
• за kubectl logs представени ново знаме --prefix, добавяйки името на групата и контейнера източник към всеки ред от дневника;
• в label.Selector добавено RequiresExactMatch;
• всички контейнери в kube-dns сега се изпълняват с по-малко привилегии;
• хиперкуб отделени в отделно хранилище на GitHub и вече няма да бъдат включени в изданията на Kubernetes;
• много подобрена производителност kube-прокси за не-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

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

• «Kubernetes 1.16: Акценти от новите неща»;
• «Kubernetes 1.15: Акценти от новите неща»;
• «Kubernetes 1.14: Акценти от новите неща»;
• «Kubernetes 1.13: Акценти от новите неща".

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