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

Тази нощ ще се състои е новият релиз на Kubernetes — 1.14. Според традицията на нашия блог, ви разказваме за основните промени в новата версия на този забележителен продукт с отворен код.

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

Да започнем с важното въведение от SIG cluster-lifecycle: динамични отказоустойчиви клъстери Kubernetes (или, по-точно, self-hosted HA deployments) вече може да бъде създаден чрез познатите (в контекста на клъстери с един възел) команди kubeadm (init и присъединете се). В кратце, за това:

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

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

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

API

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

Подробности за реализацията — в KEP. Текущата готовност — алфа-версия (преминаването към бета е планирано за следващия релиз на Kubernetes).

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

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

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

Складовете

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

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

Както и в предходната версия на Kubernetes, много значими промени са представени за активно развиващия се CSI (Container Storage Interface):

CSI

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

Още една функция за CSI в алфа-версия — възможността да се ссылае директно (т.е. без използване на PV/PVC) на CSI-томове в рамките на спецификацията на pod'ов. Това отстранява ограничението за използване на CSI само като отдалечени хранилища за данни, отваряйки за тях вратата към света на local ephemeral volumes.За употреба (пример от документацията) е необходимо да се включи CSIInlineVolume feature gate.

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

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

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

Възли / Kubelet

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

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

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

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

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

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

CLI

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

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

Освен това:

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

Други

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

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

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

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

P.S.

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

• «Kubernetes 1.13: преглед на основните нововъведения»;
• «Kubernetes 1.12: преглед на основните нововъведения»;
• «Kubernetes 1.11: преглед на основните нововъведения»;
• «Kubernetes 1.10: преглед на основните нововъведения».

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