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

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

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

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

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

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

Подробности за реализацията можете да намерите в проект за дизайн. Тази функция наистина беше дългоочаквана: алфа версията се очакваше още в 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’a (повече за него можете да прочетете в текста за изпускането на Kubernetes 1.12, където този клас възникна като алфа версия), а в Admission Webhooks е реализирана има възможност да се определят, кои версии AdmissionReview поддържат. Накрая, в правилата за Admission Webhooks сега може да се ограничава обхватът на тяхното приложение с пространства от имена и граници на клъстера.

Хранилища

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

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

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

CSI

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

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

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

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

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

Узли / Kubelet

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

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

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

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

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

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

CLI

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

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

Освен това:

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

Други

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

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

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

• Политиката RBAC по подразбиране вече не дава достъп до API discovery и access-review на потребители без удостоверяване (неудостоверени).
• Официалната поддръжка на CoreDNS се осигурява само за Linux, затова при използване на kubeadm за него (CoreDNS) разгръщане в клъстера, възлите трябва да работят само в Linux (за това ограничение се използват nodeSelectors).
• Конфигурацията на CoreDNS по подразбиране сега използва плъгин forward вместо proxy. Освен това, в CoreDNS е добавена readinessProbe, предотвратяваща балансировката на натоварването на съответстващите (неподготвени за обслужване) pod’и.
• В kubeadm, на етапите init или upload-certs, стана възможно да се качват сертификати, необходими за свързване на нов control-plane към секретa 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