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

Тази нощ ще се състои следващото издание на Kubernetes - 1.14. По традиция, създала се за нашия блог, говорим за ключовите промени в новата версия на този прекрасен Open Source продукт.

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

Нека започнем с важно въведение от жизнения цикъл на клъстера на SIG: динамични отказоустойчиви клъстери Kubernetes (или по-точно, самостоятелно хоствани внедрявания на HA) е вече може да се създаде използване на познати (в контекста на клъстери с един възел) команди kubeadm (init и join). Накратко за това:

• сертификатите, използвани от клъстера, се прехвърлят в тайни;
• за възможността за използване на клъстера etcd вътре в клъстера K8s (т.е. премахване на съществуващата преди това външна зависимост) etcd-оператор;
• Документира препоръчителните настройки за външен балансьор на натоварването, който осигурява устойчива на грешки конфигурация (в бъдеще се планира да се премахне тази зависимост, но не на този етап).

Архитектура на Kubernetes HA клъстер, създаден с kubeadm

Подробности за изпълнението можете да намерите в предложение за дизайн. Тази функция беше наистина дългоочаквана: алфа версията се очакваше още в K8s 1.9, но се появи едва сега.

API

Отбор apply и най-общо казано декларативно управление на обекти премина на kubectl в apiserver. Самите разработчици накратко обясняват решението си с това kubectl apply - фундаментална част от работата с конфигурации в Kubernetes, обаче, „тя е пълна с грешки и е трудна за коригиране“ и следователно тази функционалност трябва да бъде върната към нормалното и прехвърлена към контролната равнина. Прости и ясни примери за проблеми, които съществуват днес:

Подробности за изпълнението има в КЕП. Текущата готовност е алфа (промотирането до бета е планирано за следващото издание на Kubernetes).

Предлага се в алфа версия възможност използвайки схемата OpenAPI v3 за създаване и публикуване на OpenAPI документация за CustomResources (CR), използвани за валидиране (от страна на сървъра) дефинирани от потребителя ресурси на K8s (CustomResourceDefinition, CRD). Публикуването на OpenAPI за CRD позволява на клиенти (напр. kubectl) извършете валидиране от ваша страна (в рамките на kubectl create и kubectl apply) и издаване на документация по схемата (kubectl explain). Подробности - в КЕП.

Вече съществуващи регистрационни файлове сега се отварят със знаме O_APPEND (и не O_TRUNC), за да се избегне загуба на регистрационни файлове в някои ситуации и за удобство при съкращаване на регистрационни файлове с външни помощни програми за ротация.

Също така в контекста на API на Kubernetes може да се отбележи, че в PodSandbox и PodSandboxStatus добавен област runtime_handler за запис на информация за RuntimeClass в под (прочетете повече за това в текста за Издаване на Kubernetes 1.12, където този клас се появи като алфа версия) и в Admission Webhooks изпълнени способността да се определи кои версии AdmissionReview те подкрепят. И накрая, правилата на Admission Webhooks са вече могат да бъдат ограничени степента на тяхното използване от пространства от имена и клъстерни рамки.

Съхранение

PersistentLocalVolumes, който имаше бета статус от пускането K8s 1.10, обяви стабилен (GA): тази порта на функцията вече не е деактивирана и ще бъде премахната в Kubernetes 1.17.

Възможност използвайки променливи на средата, наречени API надолу (например името на pod) за имената на директориите, монтирани като subPath, беше разработен - под формата на ново поле subPathExpr, който сега се използва за определяне на желаното име на директория. Функцията първоначално се появи в Kubernetes 1.11, но за 1.14 остана в състояние на алфа версия.

Както при предишната версия на Kubernetes, въведени са много значителни промени за активно развиващия се CSI (интерфейс за съхранение на контейнери):

CSI

Стана наличен (като част от алфа версията) подкрепа преоразмеряване за томове на CSI. За да го използвате, ще трябва да активирате портата на функцията, наречена ExpandCSIVolumes, както и наличието на поддръжка за тази операция в конкретен CSI драйвер.

Друга функция за CSI в алфа версията - възможност препращайте директно (т.е. без да използвате PV/PVC) към обемите на CSI в рамките на спецификацията на контейнера. Това премахва ограничението за използване на CSI като изключително отдалечено съхранение на данни, отваряйки им врати към света локални ефимерни обеми. За използване (пример от документацията) трябва да е активиран CSIInlineVolume характеристика порта.

Също така има напредък във „вътрешните“ елементи на Kubernetes, свързани с CSI, които не са толкова видими за крайните потребители (системни администратори) ... В момента разработчиците са принудени да поддържат две версии на всеки плъгин за съхранение: едната - „в old way”, вътре в кодовата база на K8s (in -tree), а вторият - като част от новия CSI (прочетете повече за това, например, в тук). Това причинява разбираеми неудобства, които трябва да бъдат решени, когато самият CSI се стабилизира. Не е възможно просто да отхвърлите API на вътрешни (в дърво) плъгини поради съответната политика на Kubernetes.

Всичко това доведе до достигането на алфа версията миграционен процес вътрешен плъгин код, имплементиран като in-tree, в CSI плъгини, благодарение на което притесненията на разработчиците ще бъдат сведени до поддръжка на една версия на техните плъгини, а съвместимостта със старите API ще остане и те могат да бъдат обявени за остарели в обичайния сценарий. Очаква се до следващото издание на Kubernetes (1.15) всички приставки за облачни доставчици да бъдат мигрирани, внедряването ще получи бета статус и ще бъде активирано в инсталациите на K8s по подразбиране. За подробности вж предложение за дизайн. Тази миграция също доведе до неуспех от ограниченията на обема, определени от конкретни доставчици на облак (AWS, Azure, GCE, Cinder).

Освен това, поддръжка за блокови устройства с CSI (CSIBlockVolume) прехвърлен към бета версия.

Възли/Кубелет

Представена алфа версия нова крайна точка в Кубелет, предназначен за връщане на показатели за ключови ресурси. Най-общо казано, ако преди това Kubelet получаваше статистика за използването на контейнера от cAdvisor, сега тези данни идват от средата за изпълнение на контейнера чрез CRI (Container Runtime Interface), но съвместимостта за работа с по-стари версии на Docker също се запазва. Преди статистическите данни, събрани в Kubelet, се изпращаха чрез REST API, но сега крайна точка, разположена на /metrics/resource/v1alpha1. Дългосрочна стратегия на разработчиците е е да минимизира набора от показатели, предоставени от Kubelet. Между другото, тези самите показатели сега се обаждат не „основни показатели“, а „метрики за ресурси“ и се описват като „първокласни ресурси, като процесор и памет“.

Много интересен нюанс: въпреки ясното предимство на производителността на крайната точка на gRPC в сравнение с различни случаи на използване на формата Prometheus (вижте резултата от един от бенчмарковете по-долу), авторите предпочетоха текстовия формат на Prometheus поради ясното лидерство на тази система за наблюдение в общността.

„gRPC не е съвместим с основните тръбопроводи за мониторинг. Крайната точка ще бъде полезна само за доставяне на показатели към Metrics Server или компоненти за наблюдение, които се интегрират директно с него. Производителност на текстовия формат на Prometheus при използване на кеширане в Metrics Server достатъчно добър за да предпочетем Prometheus пред gRPC предвид широкото приемане на Prometheus в общността. След като форматът OpenMetrics стане по-стабилен, ще можем да се доближим до производителността на gRPC с прото-базиран формат."

Един от сравнителните тестове за ефективност на използването на gRPC и Prometheus формати в новата крайна точка на Kubelet за показатели. Повече графики и други подробности можете да намерите в КЕП.

Сред другите промени:

• Kubelet сега (еднократно) опитвайки се да спра контейнери в неизвестно състояние преди операции за рестартиране и изтриване.
• При използване на PodPresets сега към init контейнера добавен същата информация като за обикновен контейнер.
• Кубелет започна да използва usageNanoCores от доставчика на CRI статистика и за възли и контейнери в Windows добави статистика на мрежата.
• Информацията за операционната система и архитектурата вече се записва в етикети kubernetes.io/os и kubernetes.io/arch Възлови обекти (прехвърлени от бета към GA).
• Възможност за указване на конкретна системна потребителска група за контейнери в под (RunAsGroup, се появи в K8s 1.11) напреднал преди бета (активирано по подразбиране).
• du и намери използвани в cAdvisor, заменени внедряване на Go.

CLI

В cli-runtime и kubectl добавено -k флаг за интеграция с персонализирайте (между другото, неговото развитие сега се извършва в отделно хранилище), т.е. за обработка на допълнителни YAML файлове от специални директории за персонализиране (за подробности относно използването им вижте КЕП):

Пример за просто използване на файл персонализиране (по-сложно приложение на kustomize е възможно в рамките на наслагвания)

В допълнение:

• Добавено от нов отбор kubectl create cronjob, чието име говори само за себе си.
• В kubectl logs сега ти можеш да се комбинират знамена -f (--follow за поточно предаване на дневници) и -l (--selector за заявка за етикет).
• kubectl научил копирайте файлове, избрани чрез заместващ знак.
• Към отбора kubectl wait добавено флаг --all за да изберете всички ресурси в пространството от имена на посочения тип ресурс.

Други

Следните възможности са получили стабилен статус (GA):

• ReadinessGate, използвани в спецификацията на капсулата за определяне на допълнителни условия, взети предвид при готовността на капсулата;
• Поддръжка за големи страници (порта за функции, наречена HugePages);
• CustomPodDNS;
• API на PriorityClass Priority & Preemption на под.

Други промени, въведени в Kubernetes 1.14:

• Правилото за RBAC по подразбиране вече не позволява достъп до API discovery и access-review потребители без удостоверяване (неудостоверен).
• Официална поддръжка на CoreDNS предоставени Само за Linux, така че когато използвате kubeadm за внедряването му (CoreDNS) в клъстер, възлите трябва да работят само на Linux (NodeSelectors се използват за това ограничение).
• Конфигурацията на CoreDNS по подразбиране вече е използва плъгин за напред вместо прокси. Също така в CoreDNS добави readinessProbe, който предотвратява балансирането на натоварването на подходящи (неготови за обслужване) модули.
• В kubeadm, на фази init или upload-certs, стана възможно заредете сертификатите, необходими за свързване на новата контролна равнина към тайната на kubeadm-certs (използвайте флага --experimental-upload-certs).
• Появи се алфа версия за инсталации на Windows Подкрепа gMSA (Group Managed Service Account) – специални акаунти в Active Directory, които могат да се използват и от контейнери.
• За G.C.E. активиран mTLS криптиране между etcd и kube-apiserver.
• Актуализации в използван/зависим софтуер: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, поддръжка на Docker 18.09 в kubeadm и минималната поддържана версия на Docker API вече е 1.26.

PS

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

• «Kubernetes 1.13: Акценти от новите неща»;
• «Kubernetes 1.12: Акценти от новите неща»;
• «Kubernetes 1.11: Акценти от новите неща»;
• «Kubernetes 1.10: Акценти от новите неща".

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