днес, сряда, следваща версия на Kubernetes - 1.16. По традиция, създала се за нашия блог, това е десетата годишнина, в която говорим за най-значимите промени в новата версия.
Информацията, използвана за подготовката на този материал, е взета от , и свързани проблеми, заявки за изтегляне и предложения за подобряване на Kubernetes (KEP). И така, да тръгваме!..
Възли
Наистина голям брой забележителни иновации (в състояние на алфа версия) са представени от страна на клъстерните възли K8s (Kubelet).
Първо, т.нар «» (Ефимерни контейнери), предназначен да опрости процесите на отстраняване на грешки в pods. Новият механизъм ви позволява да стартирате специални контейнери, които започват в пространството на имената на съществуващи подове и живеят за кратко време. Тяхната цел е да взаимодействат с други подове и контейнери, за да разрешават всякакви проблеми и да отстраняват грешки. За тази функция е въведена нова команда kubectl debug, подобни по същество на kubectl exec: само вместо да изпълнява процес в контейнер (както в exec) стартира контейнер в под. Например, тази команда ще свърже нов контейнер към под:
kubectl debug -c debug-shell --image=debian target-pod -- bashПодробности за ефимерните контейнери (и примери за тяхното използване) могат да бъдат намерени в . Текущата реализация (в K8s 1.16) е алфа версия и сред критериите за нейното прехвърляне към бета версия е „тестване на API за кратковременни контейнери за поне 2 издания на [Kubernetes].“
NB: В своята същност и дори в името си функцията наподобява вече съществуващ плъгин за които ние . Очаква се, че с появата на ефимерни контейнери, разработването на отделен външен плъгин ще спре.
Друга иновация - - предназначени да предоставят механизъм за изчисляване на режийните разходи за подс, което може да варира значително в зависимост от използваното време за изпълнение. Като пример, авторите водят до Kata контейнери, които изискват стартиране на ядрото за гости, kata агент, init система и т.н. Когато режийните разходи станат толкова големи, те не могат да бъдат пренебрегнати, което означава, че трябва да има начин да се вземат предвид за по-нататъшни квоти, планиране и т.н. За да го внедрите в PodSpec добавено поле Overhead *ResourceList (сравнява се с данни в RuntimeClass, ако се използва такъв).
Друга забележителна иновация е мениджър на топология на възел (Мениджър на топология на възел), предназначен да обедини подхода за фина настройка на разпределението на хардуерни ресурси за различни компоненти в Kubernetes. Тази инициатива е продиктувана от нарастващата нужда от различни съвременни системи (от областта на телекомуникациите, машинното обучение, финансовите услуги и др.) за високопроизводителни паралелни изчисления и минимизиране на забавянията при изпълнение на операциите, за които те използват усъвършенстван CPU и възможности за хардуерно ускорение. Такива оптимизации в Kubernetes досега са постигани благодарение на различни компоненти (CPU manager, Device manager, CNI), а сега към тях ще бъде добавен единен вътрешен интерфейс, който унифицира подхода и опростява свързването на нови подобни - така наречената топология- aware - компоненти от страната на Kubelet. Подробности - в .
Диаграма на компонентите на топологичния мениджър
Следваща функция - проверка на контейнерите, докато работят (). Както знаете, за контейнери, чието стартиране отнема много време, е трудно да се получи актуален статус: те или са „убити“, преди действително да започнат да функционират, или завършват в безизходица за дълго време. Нова проверка (активирана чрез функционален портал, наречен StartupProbeEnabled) анулира - или по-скоро отлага - ефекта от всички други проверки до момента, в който подът приключи работа. Поради тази причина функцията първоначално беше наречена . За пакети, чието стартиране отнема много време, можете да анкетирате състоянието в сравнително кратки интервали от време.
В допълнение, подобрение за RuntimeClass е незабавно достъпно в бета състояние, добавяйки поддръжка за „хетерогенни клъстери“. ° С Сега изобщо не е необходимо всеки възел да има поддръжка за всеки RuntimeClass: за pods можете да изберете RuntimeClass, без да мислите за топологията на клъстера. Преди това, за да се постигне това - така че подовете да завършват на възли с поддръжка за всичко, от което се нуждаят - беше необходимо да се присвоят подходящи правила на NodeSelector и толеранси. IN Той говори за примери за употреба и, разбира се, подробности за изпълнението.
Сеть
Две важни мрежови функции, които се появиха за първи път (в алфа версия) в Kubernetes 1.16 са:
- двоен мрежов стек - IPv4/IPv6 - и съответното му „разбиране“ на ниво подове, възли, услуги. Включва IPv4-към-IPv4 и IPv6-към-IPv6 оперативна съвместимост между капсули, от капсули до външни услуги, референтни реализации (в Bridge CNI, PTP CNI и Host-Local IPAM плъгини), както и обратна съвместимост с работещи Kubernetes клъстери Само IPv4 или IPv6. Подробностите за изпълнението са включени .
Пример за показване на IP адреси от два типа (IPv4 и IPv6) в списъка с подове:
kube-master# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-controller 1/1 Running 0 20m fd00:db8:1::2,192.168.1.3 kube-minion-1 kube-master# - Нов API за крайна точка - . Той решава проблемите с производителността/мащабируемостта на съществуващия API на крайната точка, които засягат различни компоненти в контролната равнина (apiserver и т.н., крайни точки контролер, kube-прокси). Новият API ще бъде добавен към групата API за откриване и ще може да обслужва десетки хиляди бекенд крайни точки на всяка услуга в клъстер, състоящ се от хиляди възли. За да направите това, всяка услуга се нанася на N обекта
EndpointSlice, всяка от които по подразбиране има не повече от 100 крайни точки (стойността може да се конфигурира). EndpointSlice API също ще предостави възможности за бъдещото си развитие: поддръжка за множество IP адреси за всеки pod, нови състояния за крайни точки (не самоReadyиNotReady), динамична поднастройка за крайни точки.
Представеният в последното издание достигна бета версия , на име service.kubernetes.io/load-balancer-cleanup и приложен към всяка услуга с тип LoadBalancer. По време на изтриване на такава услуга, това предотвратява действителното изтриване на ресурса, докато не приключи „почистването“ на всички съответни балансиращи ресурси.
API машини
Истинският „крайъгълен камък на стабилизирането“ е в областта на Kubernetes API сървъра и взаимодействието с него. Това стана до голяма степен благодарение на прехвърляне в стабилен статус на тези, които не се нуждаят от специално представяне (CRD), които са с бета статус още от далечните дни на Kubernetes 1.7 (а това е юни 2017!). Същата стабилизация достигна до свързаните характеристики:
- с
/statusи/scaleза CustomResources; - версии за CRD, базирани на външен webhook;
- (в K8s 1.15) стойности по подразбиране (по подразбиране) и автоматично премахване на полето (подрязване) за CustomResources;
- използване на схемата OpenAPI v3 за създаване и публикуване на OpenAPI документация, използвана за валидиране на CRD ресурси от страната на сървъра.
Друг механизъм, който отдавна е познат на администраторите на Kubernetes: - също остана в бета статус за дълго време (от K8s 1.9) и сега е обявен за стабилен.
Две други функции достигнаха бета версия: и .
И единствената съществена иновация в алфа версията беше от SelfLink — специален URI, представляващ посочения обект и част от него ObjectMeta и ListMeta (т.е. част от всеки обект в Kubernetes). Защо го изоставят? Мотивация по лесен начин като липсата на реални (преодолими) причини това поле все още да съществува. По-формалните причини са да се оптимизира производителността (чрез премахване на ненужно поле) и да се опрости работата на generic-apiserver, който е принуден да обработва такова поле по специален начин (това е единственото поле, което е зададено точно преди обекта е сериализиран). Истинско остаряване (в рамките на бета) SelfLink ще се случи с Kubernetes версия 1.20, а финалната - 1.21.
Съхранение на данни
Основната работа в областта на съхранението, както и в предишните версии, се наблюдава в района . Основните промени тук бяха:
- за първи път (в алфа версия) Поддръжка на CSI плъгин за работни възли на Windows: настоящият начин на работа със съхранение също ще замени плъгините в дървото в ядрото на Kubernetes и плъгините FlexVolume от Microsoft, базирани на Powershell;
Схема за внедряване на CSI добавки в Kubernetes за Windows - възможност , въведен обратно в K8s 1.12, нарасна до бета версия;
- Подобно „промотиране“ (от алфа към бета) беше постигнато чрез възможността да се използва CSI за създаване на локални ефимерни томове ().
Въведено в предишната версия на Kubernetes (използвайки съществуващ PVC като DataSource за създаване на нов PVC) също вече получи бета статус.
Планировчик
Две забележителни промени в планирането (и двете в алфа версия):
- - възможност използвайте капсули вместо логически приложни единици за „справедливо разпределение“ на товарите (като Deployment и ReplicaSet) и коригиране на това разпространение (като твърдо изискване или като меко условие, т.е. приоритет). Функцията ще разшири съществуващите възможности за разпространение на планирани пакети, които в момента са ограничени от опции
PodAffinityиPodAntiAffinity, давайки на администраторите по-фин контрол по този въпрос, което означава по-добра висока наличност и оптимизирано потребление на ресурси. Подробности - в . - Употреба Политика на BestFit в Приоритетна функция RequestedToCapacityRatio по време на планирането на под, което ще позволи да кандидатствате („опаковане в контейнери“) както за основни ресурси (процесор, памет), така и за разширени (като GPU). За повече подробности вж .
Подове за планиране: преди да използвате политика за най-добро прилягане (директно чрез планировчик по подразбиране) и с нейното използване (чрез разширител на планировчик)
Освен това, възможността да създавате свои собствени плъгини за планиране извън основното дърво за разработка на Kubernetes (извън дървото).
Други промени
Също така в изданието на Kubernetes 1.16 може да се отбележи инициатива за наличните показатели в пълен ред, или по-точно в съответствие с към уредите на K8s. Те до голяма степен разчитат на съответните . Несъответствията възникнаха по различни причини (например някои показатели просто бяха създадени преди да се появят текущите инструкции) и разработчиците решиха, че е време да приведат всичко към един стандарт, „в съответствие с останалата част от екосистемата на Prometheus“. Текущото изпълнение на тази инициатива е в алфа състояние, което постепенно ще бъде повишено в следващите версии на Kubernetes до бета (1.17) и стабилна (1.18).
Освен това могат да се отбележат следните промени:
- Windows поддържа разработка с Kubeadm помощни програми за тази операционна система (алфа версия),
RunAsUserNameза Windows контейнери (алфа версия), Поддръжка на Group Managed Service Account (gMSA) до бета версия, монтиране/прикачване за vSphere томове. - механизъм за компресиране на данни в отговорите на API. Преди това за тези цели се използваше HTTP филтър, който налагаше редица ограничения, които не позволяваха да бъде активиран по подразбиране. „Прозрачно компресиране на заявки“ вече работи: изпращане на клиенти
Accept-Encoding: gzipв заглавката, те получават GZIP-компресиран отговор, ако размерът му надвишава 128 KB. Клиентите на Go автоматично поддържат компресия (изпращане на необходимия хедър), така че веднага ще забележат намаляване на трафика. (Може да са необходими леки модификации за други езици.) - мащабиране на HPA от/до нулеви модули въз основа на външни показатели. Ако мащабирате въз основа на обекти/външни показатели, тогава, когато работните натоварвания са неактивни, можете автоматично да мащабирате до 0 реплики, за да спестите ресурси. Тази функция трябва да бъде особено полезна за случаите, когато работниците изискват GPU ресурси и броят на различните типове неактивни работници надвишава броя на наличните GPU.
- Нов клиент - — за „генерализиран“ достъп до обекти. Той е предназначен за лесно извличане на метаданни (т.е. подраздел
metadata) от ресурсите на клъстера и изпълнява операции за събиране на отпадъци и квоти с тях. - Изградете Kubernetes без наследени („вградени“ в дърво) облачни доставчици (алфа версия).
- Към помощната програма kubeadm експериментална (алфа версия) възможност за прилагане на персонализирани корекции по време на операции
init,joinиupgrade. Научете повече за това как да използвате флага--experimental-kustomize, виж в . - Нова крайна точка за apiserver - , - ви позволява да експортирате информация за неговата готовност. API сървърът също вече има флаг
--maximum-startup-sequence-duration, което ви позволява да регулирате рестартирането му. - две функции за Azure обявен за стабилен: поддръжка (Зони на наличност) и (RG). Освен това Azure добави:
- AAD и ADFS;
-
service.beta.kubernetes.io/azure-pip-nameза указване на публичния IP на балансиращото натоварване; - настройки
LoadBalancerNameиLoadBalancerResourceGroup.
- AWS вече има за EBS на Windows и EC2 API извиквания
DescribeInstances. - Kubeadm вече е независим Конфигурация на CoreDNS при надграждане на версията на CoreDNS.
- Двоични файлове и т.н. в съответното изображение на Docker световно изпълним файл, който ви позволява да стартирате това изображение без необходимост от root права. Също така изображение за миграция на etcd поддръжка на версия etcd2.
- В преминах към използване на distroless като основно изображение, подобрена производителност, добавени нови облачни доставчици (DigitalOcean, Magnum, Packet).
- Актуализации в използван/зависим софтуер: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.
PS
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com