ProHoster > Блог > интернет новини > Издание на Kubernetes 1.18, система за управление на изолиран контейнерен клъстер

Издание на Kubernetes 1.18, система за управление на изолиран контейнерен клъстер

публикувани освобождаване на платформа за оркестриране на контейнери Kubernetes 1.18, което ви позволява да управлявате клъстер от изолирани контейнери като цяло и предоставя механизми за внедряване, поддържане и мащабиране на приложения, работещи в контейнери. Проектът първоначално е създаден от Google, но след това е прехвърлен на независим сайт, контролиран от Linux Foundation. Платформата се позиционира като универсално решение, разработено от общността, необвързано с отделни системи и способно да работи с всяко приложение във всяка облачна среда. Кодът на Kubernetes е написан на Go и разпространява се от лицензиран под Apache 2.0.

Осигурява функции за внедряване и управление на инфраструктура, като поддръжка на DNS база данни, балансиране на натоварването,
разпределение на контейнери между клъстерни възли (миграция на контейнери в зависимост от промените в натоварването и нуждите от услуги), проверки на състоянието на ниво приложение, управление на акаунти, актуализиране и динамично мащабиране на работещ клъстер, без да го спирате. Възможно е да се разположат групи от контейнери с операции за актуализиране и отмяна за цялата група наведнъж, както и логическо разделяне на клъстера на части с разделяне на ресурсите. Има поддръжка за динамична миграция на приложения, за чието съхранение на данни могат да се използват както локални системи за съхранение, така и мрежови системи за съхранение.

Изданието Kubernetes 1.18 включва 38 промени и подобрения, от които 15 са преместени в стабилен статус и 11 в бета статус. Предлагат се 12 нови промени в алфа състояние. При подготовката на новата версия еднакви усилия бяха насочени както към усъвършенстване на различни функционалности и стабилизиране на експерименталните възможности, така и към добавяне на нови разработки. Основни промени:

  • Kubectl
    • Добавено от Алфа версия на командата „kubectl debug“, която ви позволява да опростите отстраняването на грешки в подове чрез стартиране на краткотрайни контейнери с инструменти за отстраняване на грешки.
    • Обявен за стабилен командата “kubectl diff”, която ви позволява да видите какво ще се промени в клъстера, ако приложите манифеста.
    • Премахнато всички генератори на командата "kubectl run", с изключение на генератора за стартиране на един под.
    • Променен флаг “--dry-run”, в зависимост от стойността му (клиент, сървър и никой), пробното изпълнение на командата се извършва от страната на клиента или сървъра.
    • kubectl код подчертано към отделно хранилище. Това позволи на kubectl да бъде отделен от вътрешните зависимости на kubernetes и улесни импортирането на код в проекти на трети страни.
  • Влизане
    • започна промяна на API група за Ingress към networking.v1beta1.
    • Добавено нови полета:
      • pathType, който ви позволява да посочите как ще бъде сравнен пътят в заявката
      • IngressClassName е заместител на анотацията kubernetes.io/ingress.class, която е обявена за остаряла. Това поле указва името на специалния обект InressClass
    • Добавено обект IngressClass, който указва името на входния контролер, неговите допълнителни параметри и знака за използването му по подразбиране
  • обслужване
    • Добавен полето AppProtocol, в което можете да посочите кой протокол използва приложението
    • Преведено в бета състояние и активиран по подразбиране EndpointSlicesAPI, който е по-функционален заместител на обикновените крайни точки.
  • Сеть
  • Постоянни дискове. Следната функционалност е обявена за стабилна:
  • Конфигурация на приложението
    • Към ConfigMap и Secret обекти добавен ново поле "неизменно". Задаването на стойността на полето на true предотвратява модифицирането на обекта.
  • Планировчик
    • Добавено от възможност за създаване на допълнителни профили за kube-scheduler. Ако по-рано беше необходимо да се изпълняват допълнителни отделни планировчици за внедряване на нестандартни алгоритми за разпространение на pod, сега е възможно да се създадат допълнителни набори от настройки за стандартния планировчик и да се посочи името му в същото поле на pod „.spec.schedulerName“. Състояние - алфа.
    • Изгонване на базата на петна обявен за стабилен
  • мащабиране
    • Добавено от способността да се укаже в манифеста на HPA степента на агресивност при промяна на броя на работещите модули, тоест, когато натоварването се увеличи, стартирайте N пъти повече инстанции наведнъж.
  • Кубелет
    • Топологичен мениджър получи бета статус. Функцията позволява разпределение на NUMA, което избягва влошаване на производителността на системи с множество гнезда.
    • Бета състояние получих PodOverhead функция, която ви позволява да посочите в RuntimeClass допълнителното количество ресурси, необходими за стартиране на pod.
    • Разширено поддръжка за HugePages, в алфа статус добавена изолация на ниво контейнер и поддръжка за множество големи размери на страници.
    • Изтрито крайна точка за показатели /metrics/resource/v1alpha1, вместо това се използва /metrics/resource
  • API
    • Накрая Премахната е възможността за използване на остарялата група API приложения/v1beta1 и разширения/v1beta1.
    • Прилагане от страна на сървъра надграден до бета2 статус. Това подобрение премества манипулирането на обекти от kubectl към API сървъра. Авторите на подобрението твърдят, че това ще поправи много съществуващи грешки, които не могат да бъдат коригирани в настоящата ситуация. Те също така добавиха раздел „.metadata.managedFields“, в който предлагат да се съхранява историята на промените в обекта, като се посочва кой, кога и какво точно е променил.
    • Обявен стабилен CertificateSigningRequest API.
  • Поддръжка на Windows платформа.

Източник: opennet.ru

Добавяне на нов коментар