LINUX.ORG.RU
Новости — Open Source  

Kubernetes 1.20 релиз

 , ,


0

1

В новейшей версии Kubernetes 1.20, внесены следующие важные изменения:

  • Kubernetes переходит на использование стандарта Container Runtime Interface (CRI). Для запуска контейнеров теперь будет использоваться не Docker, а любая из реализаций стандарта, например containerd. Для большинства пользователей разница не будет заметна - например, любые существующие образы Docker будут работать нормально. Но проблемы могут возникнуть при работе с ограничениями ресурсов, журналированием или взаимодействием с графическими процессорами и специальным оборудованием.
  • Входящие запросы к kube-apiserver можно отсортировать по уровням приоритета, чтобы администратор мог указать, какие запросы должны быть удовлетворены в первую очередь.
  • Ограничение PID процесса теперь общедоступно. Эта функция гарантирует, что модули не могут исчерпать количество идентификаторов процессов, доступных на хосте Linux, или помешать другим модулям, используя слишком много процессов.

>>> Подробности

★★★

Проверено: Shaman007 ()
Последнее исправление: alpha (всего исправлений: 3)

 ← 1 2 3 →
Ответ на: комментарий от lx1

Самое важное, что умеет подман — работать без демона

Если говорить точнее, то контейнер управлается не демоном, а командной строкой.

Oleg_Iu ★
()
Ответ на: комментарий от lx1

Даёшь базу данных, которая работает без демона(-ов)!

Даёшь веб-сервер, который работает без демона(-ов)!

Даёшь systemd, который работает без демона(-ов)!

Даёшь операционную систему, которая работает без демона(-ов)!

anonymous
()
Ответ на: комментарий от S_Paul

В смысле GIT’а хватит? У меня код на сервер заезжает с помощью Gitlab-CI - там у меня несколько джоб, одна из которых через Rsync загоняет код на сервер, и ещё одна, которая в самом конце рестартит сервис в супервизоре. То есть Докер не используется вообще. Соответственно, я там экспериментирую, и хотелось бы хоть какие-то удобства. Например, припёрло мне ещё 1 инстанс с SSR-сервисов поднять - и получается не сильно удобно, т.к. надо в супервизорд добавлять ещё один сервер, запускать его на другом порту, в Nginx добавлять его в балансировку… Мне постоянно кажется, как будто я какой-то велосипед делаю, и надо как-то не так. Понятно, что это пет-проект, и там плевать, но всё же. Ну и, опять-таки вопрос: нужен ли тут Ansible? Или он к процессу деплоя особого отношения не имеет?

dimuska139 ★★
()
Ответ на: комментарий от alpha

Вообще это очень на Supervisord похоже. В чём принципиальная разница? Что он «умеет запускать несколько контейнеров в рамках одного пода»?

dimuska139 ★★
()
Ответ на: комментарий от Oleg_Iu

Сколько я помню, там на каждый контейнер запускается по демону, который за ним следит и если надо, перезапускает.

ugoday ★★★★★
()
Ответ на: комментарий от dimuska139

Ну так из первого сообщения этого не узнать было…

А про связку Nomad+Consul не думал? Есть конфигурация Nginx как раз. Я только не уверен, получится ли на одной ноде с этим работать. Есть ещё Minikube - однонодовый.

S_Paul ★★★★★
()
Ответ на: комментарий от dimuska139

Можно попробовать взять traefik + на выбор docker / consul / другое поддерживаемое discovery. Только он не умеет сервить статику.

К вопросу о редисе, если изоляция не нужна, то можно не делать в каждом compose-проекте свой редис, а сделать отдельный compose где будет только редис, затем каждый нужный проект добавить в его сеть примерно так:

networks:
  redis:
    name: redis_default
    extetnal: true

И соответственно каждому сервису добавить:

networks:
  - default
  - redis

Я так делаю не для redis, а для traefik, он у меня один на локалхосте для разработки, и я автоматически по имени сервиса получаю discovery и проксирование всего что надо.

anonymous
()
Ответ на: комментарий от S_Paul

Думал. Я в этом не сильно шарю, поэтому и пытаюсь выяснить, какой способ наиболее удачный для разворачивания небольших проектов на не особо мощных VPS желательно с использованием докера (потому что локально в разработке я его использую - и хотелось бы иметь одинаковые версии софта и локально, и в проде). Ну и чтобы можно было при желании без боли и страданий сменить VPS на другую.

dimuska139 ★★
()
Ответ на: комментарий от ugoday

Там, как я понимаю, runc запускает контейнер через прокладку (shim), которая и является контролечкой работы контейнера, являясь родительским процессом.

Что-то лень в доки заглядывать. :)

Oleg_Iu ★
()
Ответ на: комментарий от dimuska139

docker-compose и какой-нибудь CI/CD для его обновления. В случае кластера из одной полудохлой VPSки, чем проще решение, тем оно лучше.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Это вариант-то удобный. Но есть один момент, который мне не нравится. Обычно docker-compose.yml связан непосредственно с проектом (поэтому обычно он лежит в корне того же репозитория, что и проект). Но у меня есть некоторые вещи, которые вынесены в отдельный репозиторий. Мне в каждом репозитории делать свой docker-compose.yml, и связывать их между собой через Networks?

dimuska139 ★★
()
Ответ на: комментарий от dimuska139

Docker-compose позволяет использовать несколько файлов docker-compose и сливать их перед исполнением, либо расширять сервис с помощью определений из другого файла. Думаю что-то из этого вам поможет.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Посмотрю, но не уверен, что это поможет, т.к. это переопределение docker-compose для различных окружений (в рамках одного проекта).

dimuska139 ★★
()
Ответ на: комментарий от dimuska139

Ещё можно добавить шаг в CD, который будет из расположенных в репозиториях проектов docker-compose.yml (либо какой другой метадаты) строить единый композитный файл, который и будет исполняться. Немножко ручной возни, но это всё равно проще и надёжнее (да и дешевле), чем разбираться с K8S.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Спасибо, но погуглю еще, может есть более красивое решение. k8s вообще не вариант, т.к. для него нужно минимум 4 Гб памяти - и это точно не для маленьких VPS

dimuska139 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 →
Open Source