В этом учебном пособии Kubernetes я рассмотрел пошаговое руководство по настройке Kubernetes кластера на Vagrant. Это многонодовая настройка Kubernetes с использованием kubeadm.
Vagrant - это отличная утилита для настройки виртуальных машин на вашей локальной рабочей станции.
Это руководство в первую очередь посвящено автоматизированной настройке Kubernetes с использованием скриптов Vagrantfile и shell scripts.
Автоматическая настройка Kubernetes кластера на Vagrant
Я написал базовый Vagrantfile и скрипты, чтобы каждый мог понять и внести изменения в соответствии со своими требованиями.
Сводка настройки.
Команда
vagrant upсоздаст три виртуальные машины и настроит все основные компоненты и конфигурацию kubernetes с помощью Kubeadm.Файл kubeconfig добавляется ко всем узлам кластера, чтобы вы могли выполнять команды kubectl с любого узла.
Файл kubeconfig и токен доступа к kubernetes добавляются в папку configs, где у вас есть Vagrantfile. Вы можете использовать файл kubeconfig для подключения кластера с вашей рабочей станции.
Вы можете выключить виртуальные машины, когда они не используются, и запускать их снова, когда это необходимо. Все конфигурации кластера остаются нетронутыми без каких-либо проблем. Узлы автоматически подключаются к мастеру во время запуска.
Вы можете удалить все виртуальные машины одной командой
vagrant destroyи воссоздать установку с помощью командыvagrant upв любое время.
Kubernetes, Kubeadm, Vagrant, Github Repository
Kubeadm, Vagrantfile и скрипты расположены в репозитории Github.
Клонируйте репозиторий.
git clone https://github.com/scriptcamp/vagrant-kubeadm-kubernetesНастройка Kubernetes кластера на Vagrant
Выполните приведенные ниже действия, чтобы развернуть кластер Kubernetes и проверить все конфигурации кластера.
Шаг 1: Чтобы создать кластер, перейдите в клонированный каталог.
cd vagrant-kubeadm-kubernetesШаг 2: Выполните vagrant команду. Она развернет три узла. Один master и две worker-node. Установка и настройка Kubernetes происходит через bash script, присутствующий в папке scripts.
vagrant upПримечание: Если вы запускаете его в первый раз, Vagrant сначала загрузит образ ubuntu, упомянутый в Vagrantfile. Это одноразовая загрузка.
Шаг 3: Войдите в master-node, чтобы проверить конфигурацию кластера.
vagrant ssh masterШаг 4: Вывод списка всех нод кластера, чтобы убедиться, что worker-node подключены к master и находятся в готовом состоянии.
kubectl top nodesВы должны увидеть то, что показано ниже.
Вот и все! Вы можете начать развертывание и тестирование других приложений.
Чтобы завершить работу виртуальных машин Kubernetes, выполните команду:
vagrant haltКогда вам снова понадобится кластер, просто выполните:
vagrant upЧтобы удалить виртуальные машины:
vagrant destroy -fОбъяснение Kubeadm, Vagrantfile и Scripts
Дерево файлов vagrant репозитория.
├── Vagrantfile
├── configs
│ ├── config
│ ├── join.sh
│ └── token
└── scripts
├── common.sh
├── master.sh
└── node.shПапка configs и файлы генерируются только после первого запуска.
Как я объяснял ранее, папка config содержит файл config, token и файл join.sh.
В предыдущем разделе я уже объяснил, что такое config и token. Файл join.sh содержит команду присоединения worker-node с токеном, созданным во время инициализации master-node kubeadm.
Поскольку все ноды имеют общую папку с Vagrantfile, worker-node могут прочитать файл join.sh и автоматически присоединиться к master во время первого запуска. Это одноразовая задача.
Если вы войдете в какую-либо ноду и получите доступ к папке /vagrant, вы увидите Vagrantfile и скрипты в том виде, в каком они являются общими для виртуальных машин.
Давайте посмотрим на Vagrantfile
Vagrant.configure("2") do |config|
config.vm.provision "shell", inline: <<-SHELL
apt-get update -y
echo "10.0.0.10 master-node" >> /etc/hosts
echo "10.0.0.11 worker-node01" >> /etc/hosts
echo "10.0.0.12 worker-node02" >> /etc/hosts
SHELL
config.vm.define "master" do |master|
master.vm.box = "generic/ubuntu2004"
master.vm.hostname = "master-node"
master.vm.network "private_network", ip: "10.0.0.10"
master.vm.provider "virtualbox" do |vb|
vb.memory = 4048
vb.cpus = 2
end
master.vm.provision "shell", path: "scripts/common.sh"
master.vm.provision "shell", path: "scripts/master.sh"
end
(1..2).each do |i|
config.vm.define "node0#{i}" do |node|
node.vm.box = "generic/ubuntu2004"
node.vm.hostname = "worker-node0#{i}"
node.vm.network "private_network", ip: "10.0.0.1#{i}"
node.vm.provider "virtualbox" do |vb|
vb.memory = 2048
vb.cpus = 1
end
node.vm.provision "shell", path: "scripts/common.sh"
node.vm.provision "shell", path: "scripts/node.sh"
end
end
endКак видите, я добавил следующие IP-адреса для узлов, и он добавляется в запись файла хоста всех узлов с его именем хоста с общим блоком оболочки, который выполняется на всех виртуальных машинах.
10.0.0.10 (master)
10.0.0.11 (node 01)
10.0.0.12 (node 02)
Кроме того, блок worker-node находится в цикле. Поэтому, если вам нужно более двух worker-node или у вас только одина worker-node, вам нужно заменить 2 на нужное число в цикле. Если вы добавляете больше узлов, убедитесь, что вы добавили IP в запись файла node.
Например, для 3 worker-node необходимо иметь цикл 1..4.
(1..4).each do |i|master.sh, node.sh и common.sh
Эти три скрипта запускаются в качестве provisioners во время запуска Vagrant для конфигурирования кластера.
common.sh: - Список команд, устанавливающих docker, kubeadm, kubectl и kubelet на все узлы. Кроме того, отключает swap.
master.sh: - содержит команды для инициализации master, установки плагина calico. Кроме того, копирует файлы kube-config, join.sh и token в каталог configs.
node.sh:- читает команду join.sh из общей папки configs и присоединяется к master-node. Кроме того, скопировал файл kubeconfig в местоположение /home/vagrant/.kube для выполнения команд kubectl.
Вывод
Чтобы настроить кластер kubernetes на Vagrant, все, что вам нужно сделать, это клонировать репозиторий и запустить команду vagrant up.
Кроме того, вы инженер DevOps и работаете в кластере Kubernetes, вы можете иметь локальный стенд для разработки и тестирования.
Комментарии (38)
vainkop
02.01.2022 06:58-2Vagrant это legacy, потому что это виртуалки, а они, как известно, потребляют значительно больше системных ресурсов, чем контейнеры и поднимаются медленнее.
K3D (не путать с K3S) для этих целей подходит гораздо лучше. Можно и несколько кластеров на одной машине запустить и всё в Docker.
mrsantak
02.01.2022 13:20Vagrant это не легаси, а технология предназначенная для решения других задач. Иногда нужна именно полновесная виртуальная машина, а не докер контейнер. Другое дело, что конкретно для кубера уже есть готовые решения как на базе докера, так и на базе виртуалок.
vainkop
02.01.2022 18:09+1Иногда нужна именно полновесная виртуальная машина
Разве что для чего-то экзотического. Уверен, что более 90% остальных кейсов покроет K3D.
Можете привести пример для чего лично вам нужна именно виртуалка?
Вот так легко можно установить K3D и создать Highly Available 3 Master (!) + 3 Workers K3D cluster
curl -s https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bash k3d cluster create NAME --servers 3 --workers 3
ZlobniyShurik
02.01.2022 20:15У меня WinXp и k3d там напрямую почему-то не работает :D
А если серьёзно, то не должен софт быть жёстко привязан к конкретному серверу (дистрибутив ОС, версия ядра, состав железа, софта, e.t.c.) и виртуалки в этом смысле гораздо удобней.
vainkop
02.01.2022 20:29Не спец по куберу. Только-только начал его изучать
А если серьёзно, то не должен софт быть жёстко привязан к конкретному серверу (дистрибутив ОС, версия ядра, состав железа, софта, e.t.c.) и виртуалки в этом смысле гораздо удобней.
1) Сервера для кубера на винде не поднимают. Это можно сделать, но в мире кубера 99% линукс.
2) На винде работают некоторые ...разработчики, но докер работает практически на любой ОС, как и K3D.
3) Есть огромная разница между виртуализацией и контейнеризацией и дело не удобстве. Изучите докер.
ZlobniyShurik
02.01.2022 21:08Кто мешает в том же Hyper-V настрогать виртуалок с линем, в которые уже поселить кубер? Да, изврат, но вполне себе удобный изврат, особенно для конторы, где окошки везде, где только можно :)
Докер изучу, никуда не денусь. Правда, на курсах по куберу почему-то народ массово говорит одно "докер deprecated". Ну, не мне с ними спорить.
vainkop
02.01.2022 21:23Вы ещё и на курсах по куберу, но при этом не знаете чем VM отличается от docker и в принципе не зная докер изучаете кубер? Что за курсы такие волшебные, если не секрет?
Прочтите хоть что-то, это не долго. Например (первое нагуглилось) https://habr.com/ru/post/474068/
mrsantak
02.01.2022 21:37Правда, на курсах по куберу почему-то народ массово говорит одно "докер deprecated"
dockershim deprecated, а не docker. Если авторы курса связанного с контейнеризаций не понимают разницы, то это хороший маркер низкого качества курсов, лучше поискать другой курс. Другой маркер - это путать docker desktop и docker.
gecube
02.01.2022 21:43dockershim deprecated, а не docker.
docker-docker. Зачем нужен docker, если есть вполне себе CRI containerd?
mrsantak
02.01.2022 22:36Смотря что понимать под словом docker. Так-то этим словом нынче слишком дохрена всего обозначают, отсюда и все истории, когда docker сначало типо deprecated стал, потом типо платным.
Если речь про docker-cli, то для меня это просто удобная консольная утилита для запуска контейнеров к которой я привык и чьи флаги/команды я более-менее помню. То что кубером можно рулить по rest апи, не делает же ненужным kubectl. Так почему наличие CRI апи у containerd должно сделать ненужным docker-cli?
gecube
02.01.2022 22:45Потому что на узлах кластера ни dockerd, ни docker cli не нужны. Простой аргумент - docker cli ничего не знает о контейнерах и подах, запущенных в containerd. Именно поэтому есть отдельные утилиты crictl, nerdctl.
И, да, диагностику поломок это ничуть не ломает.
Докер стал "лишним звеном". При этом я не отрицаю, что в виду докер десктоп на машине разработчика это полезный инструмент (все ещё)
mrsantak
02.01.2022 23:01Ну если у вас на сервере есть полноценный кубер, то понятно, что вам не нужен docker. Даже если данный кластер по какой-то причине все еще работает через docker shim, то я бы сказал, что лезть в docker в обход кубера все равно не стоит.
А если же речь идет о том, чтобы просто запустить пару контейнеров, то docker решает эту задачу не привнося лишней сложности.
gecube
03.01.2022 01:56А если же речь идет о том, чтобы просто запустить пару контейнеров, то docker решает эту задачу не привнося лишней сложности.
даже тут докер не особо нужен... podman? systemd-nspawn? В конце-концов надо уточнить о чем идет речь )))) если локальная разработка - опять docker desktop (если речь идет о mac/win)
mrsantak
03.01.2022 03:46даже тут докер не особо нужен... podman? systemd-nspawn?
ОК, встречный вопрос: а зачем нужен podman и systemd-nspawn когда есть docker?
если локальная разработка - опять docker desktop (если речь идет о mac/win)
Я не понял, docker не нужен потомучто есть docker desktop?
gecube
03.01.2022 14:18Я не понял, docker не нужен потомучто есть docker desktop?
абсолютно верно. Единственный кейс, выявленный эмпирически, когда нужен именно докер - это когда есть абстракный разработчик, который сидит на линукс рабочей машине. Ну, и еще мы делали проект с CUDA - там докер тоже хорошо вписывается, потому что иначе там прямо больно становится. В остальном... его значимость переоценена.
ОК, встречный вопрос: а зачем нужен podman и systemd-nspawn когда есть docker?
тем, что оба бесплатны (абсолютно, хотя можете возразить, что и docker-ce бесплатен, см. ниже), их не планируют закрывать, а systemd-nspawn вообще в любой линукс системе есть и не требует лишних деталей.
Почему еще docker-desktop это хорошо? Потому что заплатив - Вы получаете неограниченный доступ к докер хабу и security scan'ы. Вы же помните, что безлимитный доступ к docker.io (Docker Hub) прикрыли? И многие разработчики от этого испытывают неудобства. Это означает либо организацию каких-то костылей, чтобы удобно работать, либо ... плати ...
Кстати, я ни разу не одобряю этот ход докера - стать платным. Другой вопрос, что я понимаю, что там инвесторы, все такое, мирантис, которые решили хоть какое-то бабло поднять на этом.
mrsantak
02.01.2022 21:30Сервера для кубера на винде не поднимают. Это можно сделать, но в мире кубера 99% линукс.
Кубер бывает нужен не только на серверах, но и на дев тачках. А на дев тачке может быть не только линукс, но и мак или же винда.
На винде работают некоторые ...разработчики, но докер работает практически на любой ОС, как и K3D.
Во-первых, на винде работает много разработчиков. И софта под винду тоже пишется огромное количество.
А докер работает на практически любой ОС за счет того, что, если эта ось не линукс, поднимается он в виртуалке с линуксом.
vainkop
02.01.2022 21:53Кубер бывает нужен не только на серверах, но и на дев тачках. А на дев тачке может быть не только линукс, но и мак или же винда.
Это можно долго обсуждать, но реальные сервера, на которых работают приложения, которые пишут разработчики, работают на 90+% на линуксе, а уж те, где кубер и на все 99+%. И кубер оркестрирует собственно docker/containerd/podman & etc контейнеры.
Не понимаю зачем ещё городить себе прослойку в виде Vagrant, если можно взять тот же docker desktop, который да под капотом использует виртуализацию, но спрятана она достаточно хорошо для того, чтобы не отвлекать от работы собственно с контейнерами и кубером, если нужно его поднять локально. Для этого есть специальные и популярные решения и ни одно из них не использует Vagrant: minikube, K3s, K3D & etc.
mrsantak
02.01.2022 22:07Мы кажется смешали тему треда и тему поста. Данный тред начался с утверждения, что виртуализация не нужна, а нужны контейнеры. Я тут пытаюсь донести мысль, что виртуализация очень даже нужна, иногда даже для того, чтобы пользоваться теми самыми контейнерами.
Не понимаю зачем ещё городить себе прослойку в виде Vagrant, если можно взять тот же docker desktop, который да под капотом использует виртуализацию, но спрятана она достаточно хорошо для того, чтобы не отвлекать от работы собственно с контейнерами и кубером, если нужно его поднять локально.
Если говорить про контейнеры в отрыве от k8s, то у docker desktop недавно сменилась модель лицензирования и он стал не бесплатным для комерческого использования. С учетом того, что у меня к нему в целом достаточно много претензий по качеству работы под маком, то я как раз мог бы исппользовать vagrant для запуска докера вместо docker desktop. Но у меня пришло время замены ноута и я тупо решил сменить мак на линукс и вопрос с docker desktop отпал сам собой.
Для этого есть специальные и популярные решения и ни одно из них не использует Vagrant: minikube, K3s, K3D & etc.
С этим я и не пытаюсь спорить. Вагрант для поднятия кубер кластера совершенно не нужен. Виртуалки - могут быть нужны, но вы верно заметили, что вышеупомянутые тули их достаточно грамотно абстрагируют от пользователя.
vainkop
02.01.2022 22:11Мы кажется смешали тему треда и тему поста.
Соглашусь, что мог выразиться более точно и всё высказанное мной стоит воспринимать исключительно в контексте темы поста и K8s.
sundmoon
02.01.2022 23:15Я тут пытаюсь донести мысль, что виртуализация очень даже нужна, иногда даже для того, чтобы пользоваться теми самыми контейнерами.
Вот только с данной конкретной репой на винде(virtualbox) всё непросто: приходится перезапускать провиженинг нод, всех и по отдельности.
kubeadm preflight-checks недовольны артефактами предыдущих запусков… После N-й попытки сделать up и provision всем трём нодам имеем:
vagrant@master-node:~$ hostname master-node vagrant@master-node:~$ kubectl get nodes NAME STATUS ROLES AGE VERSION vagrant Ready <none> 171m v1.20.6 vagrant@master-node:~$1) Короче, индусская какая-то репа.
Кто бы взялся починить?2) Мой личный опыт с вагрантом таков, что одной командой поднять чужую лабу почти никогда не выходит. А выкладыватели vagrant-репозиториев обычно не парятся сделать свои скрипты идемпотентными: "У меня на машине всё работает" (имеется ввиду vagrant up").
ЗЫ. (к разговорам ниже) Vagrant не нужен для запуска кубера это факт. Но вот для демонстрации kubeadm он бы сгодился… если бы код репозитория таки работал
gecube
03.01.2022 02:01можно взять https://github.com/banzaicloud/pke
Их лаба запускается (по крайней мере, у меня получались повторяемые результаты). Под капотом тот же kubeadm в конце-концов.
mrsantak
02.01.2022 21:24Разве что для чего-то экзотического.
Ну если вы сидите исключительно на линуксе и исключительно на одной архитектуре, то да, только для экзотического. А вот если вам захочется попользоваться докером на том же маке, то без виртуалки никак. Еще пример - это запуск некоторых windows приложений на линуксе/маке приходится делать через parallels.
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
gecube
02.01.2022 21:31А вот если вам захочется попользоваться докером на том же маке, то без виртуалки никак.
docker desktop решает эту проблему. Как для мака, так и для винды.
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
но не на локальных виртуалках... а, скажем, на виртуалках в копии прод окружения той же vmware, где весь остальной прод лежит.
mrsantak
02.01.2022 21:48docker desktop решает эту проблему. Как для мака, так и для винды.
А знаете как он эту проблему решает? Он поднимает вам виртуалку в которой и запускает докер. Так себе знаете аргумент в пользу ненужности виртуалок.
но не на локальных виртуалках...
А почему не на локальных? Запустили тем же вагрантом виртуалочку, подключили к ней build папочку проекта и запускаетесь себе быстро и без гемора. Не, если вы пишете софт, который даже в тестовых сценариях требует огромных ресурсов, то да, тут нужны внешние тачки. Но если речь идет про более-менее обычный софт, то проблем с локальной виртуалкой никаких.
gecube
02.01.2022 21:58А почему не на локальных? Запустили тем же вагрантом виртуалочку, подключили к ней build папочку проекта и запускаетесь себе быстро и без гемора.
я сам люблю вагрант - хороший инструмент, но если дело дошло до проблем в ядре, то вагрант тут не нужен. И, да, у вас в вагранте железо другое, чем на той же vmware, так что привет - проблемы железа вы не отловите... Поэтому ценности в нем гонять софт не так много, на самом деле, как может показаться на первый взгляд
mrsantak
02.01.2022 22:16А ну, если дело дошло до проблем с железом, то да. Там может оказаться, что и виртаулки мало, и нужно вот прям физическую железку. В конце концов SaaS мир не ограничивается и понятия прода может не быть вовсе.
А я все-таки имел ввиду класс проблем попроще - проблем связанных с ядром. Для них и меры можно попроще использовать.
vainkop
02.01.2022 22:03Еще пример - это запуск некоторых windows приложений на линуксе/маке приходится делать через parallels.
Я всё же задавал вопрос в контексте статьи про Vagrant и кубер, а не вообще зачем нужны виртуалки :)
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
При чём тут кубер, который оркестрирует контейнеры?
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
mrsantak
02.01.2022 22:23Upd. Увидел ваш коммент ниже. Кажется, что в данном треде у нас имело место банальное недопонимание. В целом, все кажется согласны с утверждением, что vagrant для запуска кубера просто напросто не нужен.
Весь тред пошел с вашего заявленияVagrant это legacy, потому что это виртуалки, а они, как известно, потребляют значительно больше системных ресурсов, чем контейнеры и поднимаются медленнее.Заметьте, в утверждении ни слова о кубере. Я пытаюсь донести мысль, что ни вагрант, ни виртуалки не являются легаси, и что у них и у контейнеров хоть и пересекающиеся, но все же разные области применения.
vainkop
02.01.2022 22:21Перечитав свой коммент понял, что как-то он слишком в общем про виртуалки получился, а не про в контексте работы Vagrant + K8s :)
Повторюсь, что конечно на винде и маке докер под капотом использует виртуализацию, но Vagrant тут совершенно лишний, т.к. есть, например, docker desktop.
kWatt
02.01.2022 13:44+1Поднять kubernetes кластер на KVM:
minikube start --driver=kvm2Поднять kubernetes кластер на VirtualBox:
minikube start --vm-driver=virtualbox
Прокинуть образ в кластер:minikube image load hello-minikube:latest
Открыть dashboard:minikube dashboard
Посмотреть список URL для доступа к сервисуhello-minikube:minikube service list
Правда есть одно "но", minikube по умолчанию делает активным сразу свой конфиг для kubectl:CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* minikube minikube minikube default
Вроде ничего сложного.
ZlobniyShurik
Не спец по куберу. Только-только начал его изучать, но, сдаётся мне, minikube ставится ещё проще. Не в укор автору топика, чисто информации для...
rudinandrey
mimikube на одной машине поднимает кубер, а тут смысл в том что создается несколько виртуальных машин, в каждой поднимается кубер и таким образом поднимается полноценный кластер.
mrsantak
Миникуб это умеет из коробки
gecube
в чем ценность? Поиграться с основными возможностями кубера с т.з. разработчика или т.з. эксплуатанта можно и на однонодовом кластере - ингресс, сетевые политики, LB etc. Да, бывают кейсы, когда хочется именно многонодовый, но их на самом деле не так много...
srgsrg1901
Миникуб это одна нода. Тут многонодовая конфа
ZlobniyShurik
Нет. Миникуб - это одна нода по умолчанию. Но многонодовые конфигурации там давным-давно работают тоже.
minikube node - add, remove, or list additional nodes