Это можно определить только опытным путем. Вот тут список поддерживаемых ОС
В предыдущей статье я устанавливал куб на CentOS с помощью kubeadm (kubespray тоже его использует кстати) и не помню чтобы выключал Selinux. Явным образом отключал только firewall, и то только потому-что не хотелось разбираться с исключениями в доступах
В инструкциях не объясняли зачем нужно включать. Но в интернете в принципе отвечают на этот вопрос
Это уже не будет high-availabe кластер, если у него один мастер. Никто не спорит с тем, что при выходе из строя мастера запущенные приложения продолжат работу. В лучшем случае хост с мастер нодой "моргнёт", ребутнется, затем поднимется и нода восстановится. А если мастер не самополечится? Полезную нагрузку (приложения и сервисы) больше нельзя будет обновить, откатить, а в случае выхода из строя нельзя будет запланировать на другую worker ноду. И толку тогда от такого кластера?
Я уже ставил кластер с одной мастер нодой на VPS серверах, они не жили больше 4 месяцев, причем ставил у разных облачных провайдеров.
В статье говорится про "production ready" кластер или если по умному high-available. Основное условие такого кластера это резервные мастер ноды, то есть необходимо иметь в запасе дополнительные ноды, которые могут быть вообще неактивными.
Почему три мастер ноды? Есть такое понятие как кворум, необходимо всегда иметь в кластере нечетное количество мастер нод, чтобы они могли между собой проголосовать кто сейчас будет "главным". Кворум используется и kubernetes кластере и в etcd кластере. Я немного упростил про выбор "главного", если интересно можно почитать про lease.
Прочитал цикл с интересом, спасибо. Лайк за наставление использовать асинхронный логгер, часто вижу в продакшн коде стандартную библиотеку.
Если кто-то решит использовать это руководство для написания продуктового кода, то обращаю внимание, что создавать сессию на каждый http запрос - это моветон. Это очень распространенная ошибка при использовании Aiohttp. Сессии надо создать и закрывать только при старте и соотвественно при закрытии приложения. Прочитать можно тут, тут
Да, спасибо за примечание. Но лично для себя решил, что лучше сделать только admin юзера, и только потом создавать других если потребуется. А то в чартах bitnami куча параметров типа user/password, global.user/global.password, auth.user/auth.password и причем некоторые из них переопределяются в зависимости указан дочерний или нет.
Спасибо за развернутый ответ. Благодаря ему я понял, что не понял изначального вопроса :). Подумал, что речь идет о создании директорий helm'ом на VPS, которые потом монтируются.
Да, согласен чарт от bitnami позволяет создать автоматом PVC. И как раз в этой инструкции при установке Redis автоматически создается PVC для slave-реплик. И вы, конечно, правы инструкцию можно еще больше упросить.
Но новичкам я бы рекомендовал некоторые вещи делать вручную, чтобы они не казались магией. Например даже инструкции от bitnami умалчивают (либо украдкой говорят) о необходимости PV и PVC. А когда ставишь чарт по рекомендованной команде, видишь, что ничего не работает из коробки.
Не видел у чартов bitnami возможность автоматически создавать директории, и вообще есть сомнения, что они могут. Может я захочу монтировать директорию на другой виртуальной машине, где даже helm не стоит?
К тому же, такой ручной контроль не особо трудозатратный, но зато наглядный - сразу понятно куда складываются данные.
Сегодня также никто не советует разворачивать продовую базу в кубе. Но для dev контура, просто поиграться, сделать демку приложения, проверить теорию вполне себе удобно.
Вот доклад на эту тему. Автор говорит, что для тестов смело разворачивайте в кубе и ничего страшного. И я с ним в этом вопросе согласен.
Признаюсь, я просто не знал что Docker как среда выполнения контейнеров устарела С:, спасибо что подсветили. Ребята, разработчики куба, в своем блоге подробно расписали, почему они так делают и как жить дальше (тут и тут)
Кратко для тех, кто впервые слышит: не надо паниковать, Docker всё также будет использоваться для разработки. Просто при установке кластера теперь надо выбирать другую среду выполнения контейнеров типа containerd и CRI-O.
В версии куба 1.20 и 1.22 всё будет работать как и раньше. В этой статье конкретно они и ставятся.
Но для следующих версий куба надо будет изменить процесс установки немного.
Так, а в чем смысл? Если знать куда бить, то конечно получится.
Вот если бы не было проблем с пропусками у уборщиков, не знать телефон зама коммерческого директора, и не знать, что были проблемы с вирусами на компе - это другое дело.
Да, как правильно заметил @F1RST для мастера минимальные - 2 CPU, 2Gb RAM. А воркер нода может быть вообще любой. Хоть 1 CPU и 1GB RAM, но логично делать, конечно, рабочие машины производительными.
А можно сделать мощную мастер ноду, включить специальную настроечку в кубе, и тогда все рабочие нагрузки будут запускаться на мастер ноде, про это выше упомянул @vesper-bot.
Главный узел - это узел, который контролирует и управляет набором рабочих узлов. На мастер узле работают следующие процессы:
1. Kube-APIServer - Вся внешняя связь с кластером осуществляется через API-сервер.
2. Kube-Controller-Manager - контроллер-менеджер реализует управление в кластере.
3. Etcd - база данных состояний кластера.
4. Kube Scheduler - планирует действия для рабочих узлов на основе событий, происходящих в etcd.
Это все запускается только на мастер ноде и нужно для управления всем кластером.
Пример: есть кластер, он состоит из одной мастер ноды ив двух воркер нод. Если выйдет из строя мастер нода, то все до свидания кластеру и нашим сервисам. А вот если выйдет из строя воркер нода, то куб это заметит, и все пользовательские ресурсы перезапустит на второй рабочей ноде, таким образом будет небольшой простой в работе сервиса. Для надежности делают резервную мастер ноду - если вдруг выходит из строя главная, то резервная мастер нода перехватывает управление кластером на себя. Такие кластеры уже называют High-Availability cluster, HA cluster.
Мастер Kubernetes отвечает за поддержание желаемого состояния для вашего кластера. Когда вы взаимодействуете с Kubernetes, например, используя интерфейс командной строки kubectl, вы работаете с мастером Kubernetes вашего кластера.
Под "мастером" понимается совокупность процессов, которые управляют состоянием кластера. Обычно все эти процессы выполняются на одном узле кластера, и поэтому этот узел называется главным (master). Мастер также может быть реплицирован для доступности и резервирования.
Вообще это хороший вопрос, пока у меня нет ответа на него). Действительно я пытался запустить elk на этом кластере, но он очень ресурсоемкий. Возможно когда нибудь придется решать эту проблему)
Мастер нода отводится чисто для обслуживания и поддержки кластера, тут не запускаются ресурсы пользователя. А вот воркер ноды обслуживают чисто клиента, в том числе и билды (если gitlab runner развернуть).
Небольшие поправочки:
Мастер узел необязательно содержит etcd ноду. Все зависит от топологии кластера.
kubelet и kube-proxy компоненты не только рабочих узлов, они в том числе запускаются на master нодах.
Надо будет опробовать kube-vip, спасибо)
Это можно определить только опытным путем. Вот тут список поддерживаемых ОС
В предыдущей статье я устанавливал куб на CentOS с помощью kubeadm (kubespray тоже его использует кстати) и не помню чтобы выключал Selinux. Явным образом отключал только firewall, и то только потому-что не хотелось разбираться с исключениями в доступах
В инструкциях не объясняли зачем нужно включать. Но в интернете в принципе отвечают на этот вопрос
В этой статье я так и разворачиваю ingress-nginx. Решение с MetalLb было в предыдущей :)
Интересно, спасибо. А что по стоимости?
Я вот в детстве ненавидел мыть посуду, а сейчас это стал какой-то медитативный процесс - даже расслабляет..
Это уже не будет high-availabe кластер, если у него один мастер. Никто не спорит с тем, что при выходе из строя мастера запущенные приложения продолжат работу. В лучшем случае хост с мастер нодой "моргнёт", ребутнется, затем поднимется и нода восстановится. А если мастер не самополечится? Полезную нагрузку (приложения и сервисы) больше нельзя будет обновить, откатить, а в случае выхода из строя нельзя будет запланировать на другую worker ноду. И толку тогда от такого кластера?
Я уже ставил кластер с одной мастер нодой на VPS серверах, они не жили больше 4 месяцев, причем ставил у разных облачных провайдеров.
В статье говорится про "production ready" кластер или если по умному high-available. Основное условие такого кластера это резервные мастер ноды, то есть необходимо иметь в запасе дополнительные ноды, которые могут быть вообще неактивными.
Почему три мастер ноды? Есть такое понятие как кворум, необходимо всегда иметь в кластере нечетное количество мастер нод, чтобы они могли между собой проголосовать кто сейчас будет "главным". Кворум используется и kubernetes кластере и в etcd кластере. Я немного упростил про выбор "главного", если интересно можно почитать про lease.
Прочитал цикл с интересом, спасибо. Лайк за наставление использовать асинхронный логгер, часто вижу в продакшн коде стандартную библиотеку.
Если кто-то решит использовать это руководство для написания продуктового кода, то обращаю внимание, что создавать сессию на каждый http запрос - это моветон. Это очень распространенная ошибка при использовании Aiohttp. Сессии надо создать и закрывать только при старте и соотвественно при закрытии приложения. Прочитать можно тут, тут
И на главной есть сноска.
Но для учебных примеров такое использование сессий норм!
Да, спасибо за примечание. Но лично для себя решил, что лучше сделать только admin юзера, и только потом создавать других если потребуется. А то в чартах bitnami куча параметров типа user/password, global.user/global.password, auth.user/auth.password и причем некоторые из них переопределяются в зависимости указан дочерний или нет.
Спасибо за развернутый ответ. Благодаря ему я понял, что не понял изначального вопроса :). Подумал, что речь идет о создании директорий helm'ом на VPS, которые потом монтируются.
Да, согласен чарт от bitnami позволяет создать автоматом PVC. И как раз в этой инструкции при установке Redis автоматически создается PVC для slave-реплик. И вы, конечно, правы инструкцию можно еще больше упросить.
Но новичкам я бы рекомендовал некоторые вещи делать вручную, чтобы они не казались магией. Например даже инструкции от bitnami умалчивают (либо украдкой говорят) о необходимости PV и PVC. А когда ставишь чарт по рекомендованной команде, видишь, что ничего не работает из коробки.
Не видел у чартов bitnami возможность автоматически создавать директории, и вообще есть сомнения, что они могут. Может я захочу монтировать директорию на другой виртуальной машине, где даже helm не стоит?
К тому же, такой ручной контроль не особо трудозатратный, но зато наглядный - сразу понятно куда складываются данные.
Сегодня также никто не советует разворачивать продовую базу в кубе. Но для dev контура, просто поиграться, сделать демку приложения, проверить теорию вполне себе удобно.
Вот доклад на эту тему. Автор говорит, что для тестов смело разворачивайте в кубе и ничего страшного. И я с ним в этом вопросе согласен.
Признаюсь, я просто не знал что Docker как среда выполнения контейнеров устарела С:, спасибо что подсветили. Ребята, разработчики куба, в своем блоге подробно расписали, почему они так делают и как жить дальше (тут и тут)
Кратко для тех, кто впервые слышит: не надо паниковать, Docker всё также будет использоваться для разработки. Просто при установке кластера теперь надо выбирать другую среду выполнения контейнеров типа containerd и CRI-O.
В версии куба 1.20 и 1.22 всё будет работать как и раньше. В этой статье конкретно они и ставятся.
Но для следующих версий куба надо будет изменить процесс установки немного.
Так, а в чем смысл? Если знать куда бить, то конечно получится.
Вот если бы не было проблем с пропусками у уборщиков, не знать телефон зама коммерческого директора, и не знать, что были проблемы с вирусами на компе - это другое дело.
Да, как правильно заметил @F1RST для мастера минимальные - 2 CPU, 2Gb RAM. А воркер нода может быть вообще любой. Хоть 1 CPU и 1GB RAM, но логично делать, конечно, рабочие машины производительными.
А можно сделать мощную мастер ноду, включить специальную настроечку в кубе, и тогда все рабочие нагрузки будут запускаться на мастер ноде, про это выше упомянул @vesper-bot.
Выкатывают приложение (или все пользовательские ресурсы) только на worker ноды.
Например тут хорошо расписано:
Это все запускается только на мастер ноде и нужно для управления всем кластером.
Пример: есть кластер, он состоит из одной мастер ноды ив двух воркер нод. Если выйдет из строя мастер нода, то все до свидания кластеру и нашим сервисам. А вот если выйдет из строя воркер нода, то куб это заметит, и все пользовательские ресурсы перезапустит на второй рабочей ноде, таким образом будет небольшой простой в работе сервиса. Для надежности делают резервную мастер ноду - если вдруг выходит из строя главная, то резервная мастер нода перехватывает управление кластером на себя. Такие кластеры уже называют High-Availability cluster, HA cluster.
Или вот с офф сайта:
Спасибо, интересный проект)
Вообще это хороший вопрос, пока у меня нет ответа на него). Действительно я пытался запустить elk на этом кластере, но он очень ресурсоемкий. Возможно когда нибудь придется решать эту проблему)
Мастер нода отводится чисто для обслуживания и поддержки кластера, тут не запускаются ресурсы пользователя. А вот воркер ноды обслуживают чисто клиента, в том числе и билды (если gitlab runner развернуть).