The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск Kubernetes 1.18, системы управления кластером изолированных контейнеров

30.03.2020 18:50

Опубликован релиз платформы оркестровки контейнеров 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", в зависимости от его значения (client, server и none) пробное исполнение команды выполняется на стороне клиента или сервера.
    • Код kubectl выделен в отдельный репозиторий. Это позволило отделить kubectl от внутренних зависимостей kubernetes и облегчило импорт кода в сторонние проекты.
  • Ingress
    • Началось изменение API group для Ingress на networking.v1beta1.
    • Добавлены новые поля:
      • pathType, позволяющее указать каким способом будет сравниваться путь в запросе
      • IngressClassName - замена аннотации kubernetes.io/ingress.class, которая объявлена deprecated. В этом поле указывается название специального объекта InressClass
    • Добавлен объект IngressClass, в котором указывается название ингресс контроллера, его дополнительные параметры и признак использования его по умолчанию
  • Service
    • Добавлено поле AppProtocol, в котором можно указать какой протокол использует приложение
    • Переведён в статус бета и включён по умолчанию EndpointSlicesAPI, который является более функциональной заменой обычных Endpoints.
  • Сеть
  • Постоянные диски. Объявлена стабильной следующая функциональность:
  • Конфигурирование приложения
    • В объекты ConfigMap и Secret добавлено новое поле "immutable". Установка значение поля в true запрещает изменение объекта.
  • Планировщик
    • Добавлена возможность создавать дополнительные профили для kube-scheduler. Если раньше требовалось запускать дополнительные отдельные планировщики для реализации нестандартных алгоритмов распределения подов, то теперь появилась возможность создать дополнительные наборы настроек для стандартного планировщика и указать его название в том же поле пода ".spec.schedulerName". Статус - альфа.
    • Taint Based Eviction объявлена стабильной
  • Масштабирование
    • Добавлена возможность указать в манифесте HPA степень агрессивности при изменении количества запущенных подов, то есть при увеличении нагрузки запускать сразу в N раз больше экземпляров (instance).
  • Kubelet
    • Topology Manager получил статус бета. Функция включает NUMA-распределение, что позволяет избежать деградации производительности на мультисокетных системах.
    • Статус бета получила функция PodOverhead, позволяющая указать в RuntimeClass дополнительное количество ресурсов, необходимое для запуска пода.
    • Расширена поддержка HugePages, в альфа статусе добавлена изоляция на уровне контейнера и поддержка нескольких размеров hugepages.
    • Удален endpoint для метрик /metrics/resource/v1alpha1, вместо него используется /metrics/resource
  • API
    • Окончательно убрали возможность использовать устаревшие API group apps/v1beta1 и extensions/v1beta1.
    • ServerSide Apply повышен до статуса бета2. Это улучшение переносит манипуляцию объектами из kubectl в API-сервер. Авторы улучшения утверждают, что это позволит починить множество существующих ошибок, которые невозможно исправлить в текущей ситуации. Также они добавили раздел ".metadata.managedFields", в котором предлагают хранить историю изменений объекта, с указанием кто, когда и что именно изменил.
    • Объявлен стабильным CertificateSigningRequest API.
  • Поддержка платформы Windows.


  1. Главная ссылка к новости (https://kubernetes.io/blog/202...)
  2. OpenNews: Опубликован план окончания поддержки CoreOS Container Linux
  3. OpenNews: Docker продал компании Mirantis часть бизнеса, связанного с платформой Docker Enterprise
  4. OpenNews: Выпуск Cilium 1.4, сетевой системы для Linux-контейнеров, основанной на BPF
  5. OpenNews: В Kubernetes 1.13 устранена критическая уязвимость, позволяющая поднять свои привилегии
  6. OpenNews: Amazon открыл код легковесной платформы виртуализации Firecracker
Автор новости: Сергей Бондарев - преподаватель курсов Kubernetes slurm.io
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52635-kubernetes
Ключевые слова: kubernetes, container
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Семен (??), 20:37, 30/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Планируют добавить создание контейнеров?
     
     
  • 2.15, RNZ (ok), 22:39, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А оно пока больше 110 на ноду не умеет (хотя в openshift запилили до 250), уж лет пять даже 500 не могут на ноду предоставить. А вот в самом docker (без k8s) можно и больше, 1000 в лёгкую.
     

  • 1.2, oopssss (?), 20:45, 30/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Чем больше с этим кубернетесом ковыряюсь, тем больше офигеваю от того насколько это неинтуитивная хрень
     
     
  • 2.3, Аноним (3), 21:06, 30/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Как OpenStack?
     
  • 2.4, Аноним (4), 21:40, 30/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Высокий порог входа? Кто то же понимает...
     
  • 2.5, Аноним (5), 23:04, 30/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Nomad от hashicorp получше будет
     
     
  • 3.25, Аноним (25), 15:33, 02/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Resource limits на контейнеры — только за деньги?
    Спасибо, идите в задницу.
     
  • 2.7, brzm (ok), 01:38, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    5 лет полёт нормальный, ЧЯДНТ?
     
     
  • 3.9, КО (?), 05:00, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если не трогать то конечно
     
  • 3.11, abu (?), 10:16, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если разворачивать на bare metal, то много чего можно сделать не так, особенно с PVC, особенно, пожалуй, 5 лет назад. Если не на bare metal, то надо платить деньги тем, кто все это дело поддерживает.

    А так, если позаниматься k8s просто в свое удовольствие, то даже порой затягивает и завораживает.

     
  • 2.16, And (??), 22:39, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем больше с этим кубернетесом ковыряюсь, тем больше офигеваю от того насколько это неинтуитивная хрень

    Скорее наоборот - тупая штука, но гибкая до неинтуитивности.

    Как никс системы. В основе "всё файл" и файлов-то всего-то 6, но сколько всего сделано неочевидного.

     

  • 1.6, Аноним (6), 23:14, 30/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    Современные кубернетесы позволяют решать такие проблемы, которых до изобретения кубернетесов - не существовало.
     
     
  • 2.10, Аноним (10), 10:15, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это каких? Оно умеет эффективно управлять балансировкой нагрузки между сервисами что позволяет вам смотреть сайтики без тормозов, если они популярные и на них сотни человек. И на сегодня это единственный настолько быстрый и одновременно стабильный инструмент. Т.к. когда разрабатываешь несколько версий приложенок контактирующих с другими и нужно протестить твою новую версию приложенки с НЕСКОЛЬКИМИ наборами РАЗНЫХ старых версий. То я плохо представляю сколько у тебя времени займет сделать это вручную на одной машине. Да и настраивать вручную балансировку нагрузки собирая свой конструктор из разных библиотек то еще удовольствие. Работал я с одной старой системой, до докеровской и даже до микросервисной, нагруженной, оно при парсинге запросов как черепаха, спасают заказчика только быстрые процессоры.
     
     
  • 3.12, abu (?), 10:27, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разговор про докеры-ранчеры-кубернетисы, обычно, сводится к двум руслам.

    Первое - мне, как обычному админу, админить все это достаточно неприятно. Куча сущностей, которая может быть нагорожена не админом, а программистом, которому ротация логов того же докера, в поднятой наспех виртуалке, как бы не нужна, до тех пор, пока не встанет колом. Также возможны сборки по сценариям, которые год назад написал индус, а потом застрелился. И - хочешь сценарии заново переписывай (и сколько это времени займет - тоже себе потрудитесь представить), а хочешь жди =чудес=.


    Второе русло это то, о чем вы тут говорите в чистом виде - да, балансировка, да, удобно разработчикам выкатывать-накатывать. И это - плюс всех этих систем, согласен.

     
     
  • 4.17, And (??), 22:51, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это не предназначено для админства. Это без админства всегда накатывается из CI\CD (есть код, который без админа делает правильно и умно будет гонять этот код, вместо ковыряний админа и админской широты эрудиции при ремонте поломок). Не администрируется по классике. Дальше вопрос организации и раздачи отвественностей. Чей коммит покрасил в красный - тот и озеленяет. За кадром оставлен инструментарий создания визуализации связей приложений. Без него - труба. В общем, что-то типа AppDynamics должно быть или в виде людей или в виде программном.

    Плюс системы не в удобстве накатки. Система чтобы во множестве взаимосогласованных сервисов по одному заменять версии, по кнопке откатывать версию, рассаживать сервисы по континентам, хранить конфигурацию в VCS (и видно, чей коммит покрасил в какой цвет).

    Но это всё уже после правильной организации. Просто так "взял и воюй" - не, так оно мало пригодно.

     
     
  • 5.22, abu (?), 08:56, 02/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот-вот, понеслось ((: Не спорю, слова типа =без него - труба=, =коммит покрасил в какой цвет= - это, да, не про админство.

    =Просто так брал и воевал=, правда, конечно, в рамках небольшого колхоза. Отсюда и вышеприведенное мнение - завораживает и интересно.

     
  • 5.23, abu (?), 09:14, 02/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, кстати, забыл еще об одном факторе. Вот вы попробуйте не поадминить такой вариант - программист ставит ранчер на VDS. О ротации логов в докере не заботится. О настройках ранчера - не заботится. О том, что на старых версиях ранчера сертификаты для кубернетиса - всего на год, он не думает, а волшебную кнопочку =обновить сертификаты= в ранчер завезли совсем недавно, то есть пару лет назад надо было веслами грести.
    Он заботится, конечно же, о том, чтобы покрасить коммиты в зеленый или что там еще у него в голове (:
    А потом, когда встает все колом, примерно через год, его и след простыл. И хорошо, если он в колхозе один такой мудреный, а не двадцать один.

     
  • 3.21, Аноним (21), 11:44, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот как сервера World of Warcraft, Aion, Guild Wars2 и прочие MMORPG без кубернетесов в aws я хз.
    Какие это просто титанические усилия тратятся на дронов, разносящих пицу, социальные сети гей-знакомств, всякие онлайн казино/пари-матчи, андроид/айос казулки/гриндилки с донатом. Ну хотя да, приколькно на карте видеть, как к тебе едет такси. Но опять, же. Может с архитектурой что то не то?
     

  • 1.13, Вшталик (?), 11:15, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да херня этот ваш кубернетес. Для тех кто не изучал в HA. И для тех кто не изучал в админство.
    Нафиг мне не сдались все эти лишнии слои где на каждом растёт латенси.
     
     
  • 2.14, ALex_hha (ok), 13:59, 31/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Да херня этот ваш кубернетес. Для тех кто не изучал в HA. И для тех кто не изучал в админство.

    Нафиг мне не сдались все эти лишнии слои где на каждом растёт латенси.

    админам локалхоста оно и не нужно, просто проходи мимо

     
     
  • 3.26, Аноним (26), 01:10, 03/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    оно не нужно всем тем у кого нет микросервисной архитектуры внутрикорпоративного продукта, а такое часто случается, когда нужна высочайшая производительность

    Если лейтенси для приложения мегаважно и приложение при этом позволяет его нужно просто развивать как огромный монолит и вот тогда да, его HA вы будете уметь сами посредством самых разных сетевых средств.

    Самая главная проблема контейнерных систем это сеть. Если бюджет и архитектура позволяет, можно создать лосслесс нетворк фабрику, создать выделенный приоритет для важных обменов (нужен коммутатор с DCB PFC) и загонять это в приоритетный V(X)LAN. Вы посмотрите что с большим и сложным приложением произойдёт если у вас TCP начнёт перезапрашивать часть потерянных фреймов.

     

  • 1.18, Аноним (18), 05:09, 01/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На работе больше 50 кластеров. В которых работает больше 300 приложений (супер мощные сервера). В теории все звучит хорошо а на практике, там 1000 костылей и подпорок чтобы все работало. А так же приличные сетевые задержки и проблемы с постоянным дропом tcp соединений.  Раньше все делали на OS и проблем не было
     
     
  • 2.19, Аноним (18), 05:10, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    OS - openstack
     
  • 2.20, And (??), 10:44, 01/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Обратная сторона модности-молодёжности.

    Оно действительно сырое и чтобы коллектив осилил надо набирать или людей уровня крупнейщих софтверных корпораций или использовать стабильные, отработанные технологии. А так-то, да, людям трудно успевать и за этим весь ожидаемый и предсказуемый _заранее_ негатив от инноваций. Хороша ложка к обеду. Да вот только слышат звон, а где - не осиливают.

    А чтобы набрать такую команду, надо поработать... над самим собой, чтобы не допустить: из под палки по принципу "деньги-плачу-вали-работай"+"ну-на-и-отвяжись", коммуникации сломанные, конфигурации костыльные в лучшем случае (в худшем - анекдоты), по вакансиям мало кто согласен на такое.

    Вот такие вот инновации.

     
     
  • 3.24, abu (?), 09:18, 02/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Полностью согласен (:
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру