Миналата седмица стартирането на новата версия на платформата за оркестрация на контейнери Kubernetes 1.18, версия, която включва 38 промени и подобрения, от които 15 са в стабилно състояние и 11 са в бета състояние, освен Предлагат се 12 нови промени в алфа състоянието. При подготовката на новата версия справедливи усилия бяха насочени както към усъвършенстване на различни функции, така и към стабилизиране на експерименталните способности, както и включване на нови разработки.
За тези, които не са запознати с Kubernetes, трябва да знаете това това е съоръжение за оркестрация на контейнери че ви позволява да управлявате клъстер от изолирани контейнери като цяло и осигуряват механизми за разполагане, поддържане и мащабиране на приложения, които се изпълняват в контейнери.
Проектът първоначално е създаден от Google, но по-късно е прехвърлен на отделна платформа, подготвен от Linux Foundation. Платформата се позиционира като универсално решение, разработено от общността, не е свързано с отделни системи и способно да работи с всяко приложение във всяка облачна среда. Кодът на Kubernetes е написан в Go и се разпространява под лиценза Apache 2.0.
Какво е новото в Kubernetes 1.18?
Тази нова версия на Kubernetes идва с различни подобрения за Kubectl, от които е посочено в рекламата, че добави алфа версия на командата "kubectl debug", което улеснява отстраняването на грешки в шушулки при стартиране на контейнери с инструменти за отстраняване на грешки.
Докато командата „Kubectl diff“ е обявен за стабилен, което ви позволява да видите какво ще се промени в клъстера, ако приложите манифеста.
също всички генератори на команди "kubectl run" са премахнати, с изключение на стартирането на единичен генератор на шушулки, плюс индикатора –Dry-run беше промененв зависимост от стойността му (клиент, сървър и няма), тестовото изпълнение на командата се извършва от страна на клиента или сървъра.
Кодът kubectl се присвоява на отделно хранилище. Това ни позволи да отделим kubectl от вътрешните зависимости на kubernetes и улесни импортирането на код в проекти на трети страни.
Относно мрежови промени се отбелязва, че поддръжката на IPv6 вече е в бета версия, Добавено е PVC клониране, възможност за мрежово заключване на сурови устройства като постоянни дискове, поддръжка за блокиране на сурови устройства в CSI, трансфер на информация за устройството, което иска да свърже диск с контролера на CSI, плюс това, че има ново "неизменяемо" поле е добавен към обектите ConfigMap и Secret.
От останалите промени, които се открояват:
- Възможността за използване на оттеглените API групи / v1beta1 приложения и / v1beta1 разширения беше окончателно премахната.
- ServerSide Apply актуализиран до бета2 състояние. Това подобрение носи манипулация на обект kubectl към API сървъра.
- API на CertificateSigningRequest обявен за стабилен.
- Поддръжка на платформата Windows.
- Поддръжката на Windows възел продължава да се разширява
- Поддръжка на CRI-ContainerD
- Прилагане на RuntimeClass
- CSI прокси
- Прехвърлената поддръжка е стабилна
- Групово управляван акаунт за услуги
- RunAsUserName
- Topology Manager е получил бета статус. Функцията включва NUMA дистрибуция, която предотвратява влошаване на производителността на системи с много сокети.
- Бета състоянието е получено с помощта на функцията PodOverhead, която ви позволява да посочите в RuntimeClass допълнителното количество ресурси, необходими за стартиране на дома.
- Разширена поддръжка на огромни страници, статус на алфа изолация, добавен към контейнера и поддръжка за многостепенни размери на огромни страници.
- Добавено е поле AppProtocol, където можете да посочите кой протокол използва приложението
- Преведено в бета състояние и активирано по подразбиране EndpointSlicesAPI, което е по-функционален заместител на обикновените крайни точки.
- Добавен е обект IngressClass, указващ името на входния контролер, неговите допълнителни параметри и знака, който да го използва по подразбиране.
- Добавена е възможността да се посочи в HPA манифеста на степента на агресивност при промяна на броя на домовете в експлоатация, тоест, когато натоварването се увеличи, веднага започва N пъти повече копия.