image

Привет! Все больше облачных провайдеров по всему миру предлагают свои услуги по управляемому Kubernetes кластеру в их облаках. Стоимость таких сервисов практически всегда является ключевым фактором при выборе вендора, а молодые компании с отрицательной прибылью но очень большими амбициями вовсе вынуждены отдавать последние деньги за кластер, который мог бы заменить обычный Shared-хостинг за 150 рублей в месяц. Давайте разберемся.

Почему всем компаниям нужен свой кластер?


Действительно, как и я сказал — микро-компании не нуждаются во всех прелестях k8s, им не нужен сверхвысокий UPTime их сервисов, им не требуется создавать кучу нод и ингрессов чтобы разрулить их трафик, да и желаемое масштабирование произойдет еще не завтра. Что им действительно нужно — это иметь потенциал быстрого перехода на более мощное железо, которое будет полностью удовлетворять все их быстро-растущие потребности, а kubernetes позволяет построить инфраструктуру продукта и легко перенести уже готовые спецификации на другой, например High Available (Отказоустойчивый) кластер, как только в этом появится потребность.

Думаю, все программисты согласятся, что закладывать возможность масштабирования необходимо изначально, но не все думают, как это масштабирование реализовать с точки зрения devops практик. Kubernetes звучит сложно и опасно, однако, давайте я расскажу, как поднять свой кластер за 5 минут и пару тысяч рублей в месяц, который будет полностью удовлетворять потребностям небольших компаний, и который можно будет легко преобразовать в dev-кластер, или вовсе отбросить как нижнюю часть ракеты, как только появится необходимость в отказоустойчивом кластере с кучей админов на борту.

Шаг 0. Купить сервер


В этой статье я буду создавать кластер k8s на одном выделенном сервере, который я разделю на виртуальные машины потому что это дешево. Такой подход даст компании возможность безболезненно масштабировать продукт, перейдя на любой другой кластер за 30 минут. Если у вас уже есть потребность в отказоустойчивости — арендуйте несколько виртуальных машин и пропустите первый шаг.

Долго останавливаться на этом шаге я не хочу, статья не совсем о железе. Вот минимальные требования к каждой ноде, взятые с официальной документации opensource решения, которое мы будем использовать.

image

В моем случае получилось арендовать Dedicated сервер за 3 000 рублей в месяц:

  • CPU: Intel® Xeon® Processor Quad Core 2xL5630.
  • RAM: DDR3 DIMM 4Gb 1333MHz * 6 (24гб оперативной памяти).
  • DISK: 500GB SSD 2.5 Sata3.
  • OS: Ubuntu 22.04 LTS.

Результат команды screenfetch

Шаг 1. Виртуальные машины


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

Чтобы обеспечить нашему кластеру полноценное масштабирование между нодами (именно такая среда будет при переходе на «взрослый» кластер) — создадим виртуальные машины на нашем выделенном сервере.

Советую это делать с помощью opensource-инструмента под названием Cockpit. Сам инструмент позволяет администрировать сервер через web-интерфейс. Однако нам нужен именно аддон к нему — cockpit-machines. Аддон позволяет создавать виртуальные машины, быстро и гибко. Работает на Qemu-KVM.

Подключаемся по SSH к нашему выделенному серверу и выполняем команду:

apt-get install cockpit cockpit-machines

После того как установка завершилась — заходим в браузер и переходим на ip:9090
Логин и пароль от панели управления cockpit те же, что и от SSH, то есть логин и пароль вашего пользователя ОС.

Переходим во вкладку Virtual Machines, и нажимаем "Create VM". Указываем название виртуальной машины, образ, диск и количество оперативной памяти.

Создание одной ВМ

Отлично! После завершения процесса установки ОС — мы получим нашу master-ноду. Проделываем тоже самое еще пару раз для двух worker-нод.

По итогу получим что-то вроде этого:

Список готовых ВМ

Затем заходим в каждую из ВМ и в VNC консоле устанавливаем ssh.

apt-get install ssh

Готово! Теперь у нас есть три рабочих виртуальных машины, которые мы будем использовать для нашего кластера.

Шаг 2. Настраиваем ВМ


Если вы думали, что на этом шаге мы будем редактировать и изменять кучу конфигурационных файлов для каждой виртуальной машины — забудьте. Что нам нужно сделать — это лишь установить пару пакетов и добавить чуть-чуть сахара. Но нужно быть внимательным, так как легко запутаться между этими виртуальными машинами.

Заходим по SSH в главный dedicated сервер, внутри которого мы только что создали 3 виртуальные машины. Тот, что смотрит наружу своим IP v4. Выполняем следующие команды:

apt-get install nano
nano /etc/hosts

Добавляем в самый конец 3 строчки вида IP_Виртуальной_машины название.

В моем примере это выглядит вот так:

192.168.122.61 master-node
192.168.122.172 worker-node-1
192.168.122.105 worker-node-2

После того как вставили текст — копируем его, он нам еще пригодиться, затем нажимаем ctrl+x, y и enter.

Затем, мы по очереди подключаемся к каждой виртуальной машине, чтобы установить на них дополнительные пакеты.

ssh ubuntu@master-node

su root

nano /etc/hosts

Вставляем те 3 строчки, что мы скопировали ранее и снова ctrl+x, y и enter чтобы сохранить.

Устанавливаем необходимые пакеты для каждой ноды нашего кластера.

apt-get install conntrack socat

Теперь необходимо добавить нашего пользователя ubuntu в список пользователей с доступом к sudo:

nano /etc/sudoers

После строчек:

# User privilege specification
root    ALL=(ALL:ALL) ALL

Добавляем строчку:

ubuntu  ALL=(ALL:ALL) ALL

Сохраняем (ctrl+x, y, enter).

Готово! Мы настроили мастер ноду, выходим из нее с помощью команды exit. Тот же процесс делаем с другими двумя виртуальными машинами, то есть в итоге нам нужно сделать эти шаги ВО ВСЕХ нодах нашего кластера.

После того, как мы проделали те же шаги на всех трех виртуальных машинах — снова подключаемся к мастер ноде и вводим пароль.

ssh ubuntu@master-node

Шаг 3. Создаем кластер


Этого шага боятся не только программисты, но и неопытные devops инженеры. Кажется, так сложно создать свой кластер, но нет, мы сделаем это быстро и очень просто, а поможет нам один opensource проект под названием KubeSphere.

KubeSphere — распределенная операционная система для управления cloud-native приложениями, использующая в качестве ядра Kubernetes. А так же эта система поможет себя установить за пару кликов.

Это opensource решение с более чем 13 тысячами звездочек на гитхабе и достаточно внушительным комьюнити. Оно также активно используется китайскими компаниями, которые строят большие отказоустойчивые системы.

Сейчас мы — пользователь ubuntu с sudo доступом, находимся мы в master-node в нашей домашней директории (/home/ubuntu). Выполняем следующие команды:

curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -
chmod +x kk
./kk create config -f config.toml

Эти команды скачали инструмент под названием KubeKey (kk), который позволит нам установить KubeSphere. А так же создали конфиг кластера, который сейчас мы начнем редактировать.

Открываем еще горячий config.toml:

nano config.toml

Я подчеркнул то, что нас интересует, но вы можете поиграться с конфигурациями, если вам это интересно. Kubesphere мощный инструмент, возможно, вы найдете настройки, которые необходимы для вашего кластера.

Пример нашего конфигурационного toml файла

В значении name указываем название нашего кластера, для нашего примера я оставлю sample.
В списке hosts указываем наши виртуальные сервера:

  - {name: master, address: 192.168.122.61, internalAddress: 192.168.122.61, user: ubuntu, password: "password"}
  - {name: worker-1, address: 192.168.122.172, internalAddress: 192.168.122.172, user: ubuntu, password: "password"}
  - {name: worker-2, address: 192.168.122.105, internalAddress: 192.168.122.105, user: ubuntu, password: "password"}

А чуть ниже назначаем им роли:

  roleGroups:
    etcd:
    - master
    control-plane:
    - master
    worker:
    - worker-1
    - worker-2

По итогу мы должны получить что-то вроде такого (естественно с IP адресами и паролями ваших виртуальных машин):

Пример нашего конфигурационного toml файла

Сохраняем и радуемся, мы настроили наш кластер. Осталось его только поднять. А сделать это еще проще — выполняем одну команду:

./kk create cluster --with-kubesphere -f config.toml

KubeKey проверит ноды кластера и если все ОК — попросит подтвердить установку кластера. Вводим yes и нажимаем enter.

KubeKey проверил ноды

Почти готово! Идем пить кофе или воду, если железо кластера очень старое, а интернет медленный — можно и в зал успеть сходить. Однако у меня установка кластера заняла буквально минут 5. Как только установка завершена — вы увидите следующее сообщение:

Кластер установлен

Мы можем побежать смотреть на этот великолепный интерфейс, но нас будет ожидать ошибка. Почему? Ну ты чего, ip же публичный, но он доступен только внутри сети наших виртуальных машин. Можно попытаться прокинуть внешний мост, форвардить трафик на виртуальную машину, но я сделаю намного проще.

Шаг 4. Заключительный


Открываем наш терминал и подключаемся по SSH к «Главному» выделенному серверу, тот, в котором мы создавали 3 виртуальные машины. Выполняем следующие команды:

apt-get install nginx
nano /etc/nginx/sites-enabled/default

Удаляем от туда все и вставляем следующее:

server {
        listen 30880 default_server;
        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass http://ip_из_сообщения_от_kubekey:30880;
        }
}

Сохраняем и идем в браузер по нашему публичному IP и порту 30880. Указываем логин и пароль который так же был в том сообщении после установки (по умолчанию это admin:P@88w0rd) и устанавливаем свой новый пароль.

Результат

Поздравляю! Вот ваш собственный Managed Kubernetes, который вы сможете легко настроить, подключить пайплайны гитлаба и положить туда целую кучу своих драгоценных ямлов.

В следующих статьях я постараюсь описать прочие необходимые каждой компании процессы: настройка пайплайнов, деплойменты, балансировка нагрузки и сертифицирование, опираясь на уже имеющиеся результаты этой статьи.

Ссылочки на все ресурсы:




Возможно, захочется почитать и это:


Комментарии (8)


  1. osada
    11.08.2023 12:47
    +1

    Поздравляю! Вот ваш собственный Managed Kubernetes, который вы сможете легко настроить, подключить пайплайны гитлаба и положить туда целую кучу своих драгоценных ямлов

    Правильно ли я понимаю, что после запуска этого решения K8S, все команды (kubectl и др.), которые используются в облаках Azure или AWS, будут также тут работать?

    Можно ли использовать данное кластерное решение для подготовки сдачи экзаменов по Куберу?


    1. Twelvee Автор
      11.08.2023 12:47
      +1

      Конечно! Kubectl это инструмент написанный на Go, cli интерфейс для работы с вашим кластером. Кажется что вам лучше использовать обычный minikube, разворачивается в 1 клик на одной виртуальной машине, даже делить ничего не потребуется.

      Если все же хочется использовать kubesphere, например из-за удобной веб-панели, то смело используйте материал из моей статьи, но, будет проще пропустить первый шаг и арендовать 3 виртуальных сервера (у каждого сервера будет публичный IP). Это позволит избежать проблем с проксированием запросов к кластеру.


      1. osada
        11.08.2023 12:47
        +1

        Спасибо


  1. BanaKing
    11.08.2023 12:47
    +4

    Удалось поставить по вашему гайду, хорошо что узнал про kubesphere, очень удобный инструмент.

    Единственное, советовал бы читателям сразу идти на платформу kubesphere, и устанавливать по их гайду. Поскольку в текущем был указан метод создания конфига

    ./kk create config -f config.toml

    Что конечно создаст вам кластер, но без сервисов kubesphere ( что не даст вам админку от kubesphere, как в статье).

    Как указано в оригинальной инструкции , необходимо добавить флаг --with-kubesphere, и тогда установка будет аналогичной той, что в статье.


    1. Twelvee Автор
      11.08.2023 12:47

      Действительно, забыл добавить данный флаг в статью. Обновил


  1. MrFrizzy
    11.08.2023 12:47

    Если нужен просто контроллер k8s без отказоустойчивости, то k0s позволяет запустить контроллер + воркер в пару команд:

    curl -sSLf https://get.k0s.sh | sudo sh
    sudo k0s install controller --single
    sudo k0s start
    

    либо в докере

    docker run -d --name k0s --hostname k0s --privileged -v /var/lib/k0s:/var/lib/k0s --network host docker.io/k0sproject/k0s:v1.27.4-k0s.0
    

    Подробнее здесь и здесь. Дальше можно добавлять воркеры на соседних хостах.

    Если нужен отказоустойчивый контроллер и в принципе управляемость кластером, то есть простая утилита k0sctl. С ее помощью можно легко и быстро раскатать кластер на любое количество машин по ssh. Так же k0s поддерживает и другие способы установки и настройки.

    Если хочется HA контроллер тоже в докере, например, для тестов - вот моя конфигурация.

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


    1. osada
      11.08.2023 12:47

      Пока самый большой подводный камень, который я нашел, - это необходимость рестартовать контроллер раз в год для перегенерации сертификатов.

      Используется по умолчанию стандартный Let's encrypt?


      1. MrFrizzy
        11.08.2023 12:47

        Самоподписанные, как и у всех других утилит для генерации конфигов кластера...