Комментарии 38
Не спец по куберу. Только-только начал его изучать, но, сдаётся мне, minikube ставится ещё проще. Не в укор автору топика, чисто информации для...
mimikube на одной машине поднимает кубер, а тут смысл в том что создается несколько виртуальных машин, в каждой поднимается кубер и таким образом поднимается полноценный кластер.
Миникуб это умеет из коробки
таким образом поднимается полноценный кластер.
в чем ценность? Поиграться с основными возможностями кубера с т.з. разработчика или т.з. эксплуатанта можно и на однонодовом кластере - ингресс, сетевые политики, LB etc. Да, бывают кейсы, когда хочется именно многонодовый, но их на самом деле не так много...
Миникуб это одна нода. Тут многонодовая конфа
Vagrant это legacy, потому что это виртуалки, а они, как известно, потребляют значительно больше системных ресурсов, чем контейнеры и поднимаются медленнее.
K3D (не путать с K3S) для этих целей подходит гораздо лучше. Можно и несколько кластеров на одной машине запустить и всё в Docker.
Vagrant это не легаси, а технология предназначенная для решения других задач. Иногда нужна именно полновесная виртуальная машина, а не докер контейнер. Другое дело, что конкретно для кубера уже есть готовые решения как на базе докера, так и на базе виртуалок.
Иногда нужна именно полновесная виртуальная машина
Разве что для чего-то экзотического. Уверен, что более 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У меня WinXp и k3d там напрямую почему-то не работает :D
А если серьёзно, то не должен софт быть жёстко привязан к конкретному серверу (дистрибутив ОС, версия ядра, состав железа, софта, e.t.c.) и виртуалки в этом смысле гораздо удобней.
Не спец по куберу. Только-только начал его изучать
А если серьёзно, то не должен софт быть жёстко привязан к конкретному серверу (дистрибутив ОС, версия ядра, состав железа, софта, e.t.c.) и виртуалки в этом смысле гораздо удобней.
1) Сервера для кубера на винде не поднимают. Это можно сделать, но в мире кубера 99% линукс.
2) На винде работают некоторые ...разработчики, но докер работает практически на любой ОС, как и K3D.
3) Есть огромная разница между виртуализацией и контейнеризацией и дело не удобстве. Изучите докер.
Кто мешает в том же Hyper-V настрогать виртуалок с линем, в которые уже поселить кубер? Да, изврат, но вполне себе удобный изврат, особенно для конторы, где окошки везде, где только можно :)
Докер изучу, никуда не денусь. Правда, на курсах по куберу почему-то народ массово говорит одно "докер deprecated". Ну, не мне с ними спорить.
Вы ещё и на курсах по куберу, но при этом не знаете чем VM отличается от docker и в принципе не зная докер изучаете кубер? Что за курсы такие волшебные, если не секрет?
Прочтите хоть что-то, это не долго. Например (первое нагуглилось) https://habr.com/ru/post/474068/
del
Правда, на курсах по куберу почему-то народ массово говорит одно "докер deprecated"
dockershim deprecated, а не docker. Если авторы курса связанного с контейнеризаций не понимают разницы, то это хороший маркер низкого качества курсов, лучше поискать другой курс. Другой маркер - это путать docker desktop и docker.
dockershim deprecated, а не docker.
docker-docker. Зачем нужен docker, если есть вполне себе CRI containerd?
Смотря что понимать под словом docker. Так-то этим словом нынче слишком дохрена всего обозначают, отсюда и все истории, когда docker сначало типо deprecated стал, потом типо платным.
Если речь про docker-cli, то для меня это просто удобная консольная утилита для запуска контейнеров к которой я привык и чьи флаги/команды я более-менее помню. То что кубером можно рулить по rest апи, не делает же ненужным kubectl. Так почему наличие CRI апи у containerd должно сделать ненужным docker-cli?
Потому что на узлах кластера ни dockerd, ни docker cli не нужны. Простой аргумент - docker cli ничего не знает о контейнерах и подах, запущенных в containerd. Именно поэтому есть отдельные утилиты crictl, nerdctl.
И, да, диагностику поломок это ничуть не ломает.
Докер стал "лишним звеном". При этом я не отрицаю, что в виду докер десктоп на машине разработчика это полезный инструмент (все ещё)
Ну если у вас на сервере есть полноценный кубер, то понятно, что вам не нужен docker. Даже если данный кластер по какой-то причине все еще работает через docker shim, то я бы сказал, что лезть в docker в обход кубера все равно не стоит.
А если же речь идет о том, чтобы просто запустить пару контейнеров, то docker решает эту задачу не привнося лишней сложности.
А если же речь идет о том, чтобы просто запустить пару контейнеров, то docker решает эту задачу не привнося лишней сложности.
даже тут докер не особо нужен... podman? systemd-nspawn? В конце-концов надо уточнить о чем идет речь )))) если локальная разработка - опять docker desktop (если речь идет о mac/win)
даже тут докер не особо нужен... podman? systemd-nspawn?
ОК, встречный вопрос: а зачем нужен podman и systemd-nspawn когда есть docker?
если локальная разработка - опять docker desktop (если речь идет о mac/win)
Я не понял, docker не нужен потомучто есть docker desktop?
Я не понял, docker не нужен потомучто есть docker desktop?
абсолютно верно. Единственный кейс, выявленный эмпирически, когда нужен именно докер - это когда есть абстракный разработчик, который сидит на линукс рабочей машине. Ну, и еще мы делали проект с CUDA - там докер тоже хорошо вписывается, потому что иначе там прямо больно становится. В остальном... его значимость переоценена.
ОК, встречный вопрос: а зачем нужен podman и systemd-nspawn когда есть docker?
тем, что оба бесплатны (абсолютно, хотя можете возразить, что и docker-ce бесплатен, см. ниже), их не планируют закрывать, а systemd-nspawn вообще в любой линукс системе есть и не требует лишних деталей.
Почему еще docker-desktop это хорошо? Потому что заплатив - Вы получаете неограниченный доступ к докер хабу и security scan'ы. Вы же помните, что безлимитный доступ к docker.io (Docker Hub) прикрыли? И многие разработчики от этого испытывают неудобства. Это означает либо организацию каких-то костылей, чтобы удобно работать, либо ... плати ...
Кстати, я ни разу не одобряю этот ход докера - стать платным. Другой вопрос, что я понимаю, что там инвесторы, все такое, мирантис, которые решили хоть какое-то бабло поднять на этом.
Сервера для кубера на винде не поднимают. Это можно сделать, но в мире кубера 99% линукс.
Кубер бывает нужен не только на серверах, но и на дев тачках. А на дев тачке может быть не только линукс, но и мак или же винда.
На винде работают некоторые ...разработчики, но докер работает практически на любой ОС, как и K3D.
Во-первых, на винде работает много разработчиков. И софта под винду тоже пишется огромное количество.
А докер работает на практически любой ОС за счет того, что, если эта ось не линукс, поднимается он в виртуалке с линуксом.
Кубер бывает нужен не только на серверах, но и на дев тачках. А на дев тачке может быть не только линукс, но и мак или же винда.
Это можно долго обсуждать, но реальные сервера, на которых работают приложения, которые пишут разработчики, работают на 90+% на линуксе, а уж те, где кубер и на все 99+%. И кубер оркестрирует собственно docker/containerd/podman & etc контейнеры.
Не понимаю зачем ещё городить себе прослойку в виде Vagrant, если можно взять тот же docker desktop, который да под капотом использует виртуализацию, но спрятана она достаточно хорошо для того, чтобы не отвлекать от работы собственно с контейнерами и кубером, если нужно его поднять локально. Для этого есть специальные и популярные решения и ни одно из них не использует Vagrant: minikube, K3s, K3D & etc.
Мы кажется смешали тему треда и тему поста. Данный тред начался с утверждения, что виртуализация не нужна, а нужны контейнеры. Я тут пытаюсь донести мысль, что виртуализация очень даже нужна, иногда даже для того, чтобы пользоваться теми самыми контейнерами.
Не понимаю зачем ещё городить себе прослойку в виде Vagrant, если можно взять тот же docker desktop, который да под капотом использует виртуализацию, но спрятана она достаточно хорошо для того, чтобы не отвлекать от работы собственно с контейнерами и кубером, если нужно его поднять локально.
Если говорить про контейнеры в отрыве от k8s, то у docker desktop недавно сменилась модель лицензирования и он стал не бесплатным для комерческого использования. С учетом того, что у меня к нему в целом достаточно много претензий по качеству работы под маком, то я как раз мог бы исппользовать vagrant для запуска докера вместо docker desktop. Но у меня пришло время замены ноута и я тупо решил сменить мак на линукс и вопрос с docker desktop отпал сам собой.
Для этого есть специальные и популярные решения и ни одно из них не использует Vagrant: minikube, K3s, K3D & etc.
С этим я и не пытаюсь спорить. Вагрант для поднятия кубер кластера совершенно не нужен. Виртуалки - могут быть нужны, но вы верно заметили, что вышеупомянутые тули их достаточно грамотно абстрагируют от пользователя.
Мы кажется смешали тему треда и тему поста.
Соглашусь, что мог выразиться более точно и всё высказанное мной стоит воспринимать исключительно в контексте темы поста и K8s.
Я тут пытаюсь донести мысль, что виртуализация очень даже нужна, иногда даже для того, чтобы пользоваться теми самыми контейнерами.
Вот только с данной конкретной репой на винде(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 он бы сгодился… если бы код репозитория таки работал
можно взять https://github.com/banzaicloud/pke
Их лаба запускается (по крайней мере, у меня получались повторяемые результаты). Под капотом тот же kubeadm в конце-концов.
Разве что для чего-то экзотического.
Ну если вы сидите исключительно на линуксе и исключительно на одной архитектуре, то да, только для экзотического. А вот если вам захочется попользоваться докером на том же маке, то без виртуалки никак. Еще пример - это запуск некоторых windows приложений на линуксе/маке приходится делать через parallels.
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
А вот если вам захочется попользоваться докером на том же маке, то без виртуалки никак.
docker desktop решает эту проблему. Как для мака, так и для винды.
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
но не на локальных виртуалках... а, скажем, на виртуалках в копии прод окружения той же vmware, где весь остальной прод лежит.
docker desktop решает эту проблему. Как для мака, так и для винды.
А знаете как он эту проблему решает? Он поднимает вам виртуалку в которой и запускает докер. Так себе знаете аргумент в пользу ненужности виртуалок.
но не на локальных виртуалках...
А почему не на локальных? Запустили тем же вагрантом виртуалочку, подключили к ней build папочку проекта и запускаетесь себе быстро и без гемора. Не, если вы пишете софт, который даже в тестовых сценариях требует огромных ресурсов, то да, тут нужны внешние тачки. Но если речь идет про более-менее обычный софт, то проблем с локальной виртуалкой никаких.
А почему не на локальных? Запустили тем же вагрантом виртуалочку, подключили к ней build папочку проекта и запускаетесь себе быстро и без гемора.
я сам люблю вагрант - хороший инструмент, но если дело дошло до проблем в ядре, то вагрант тут не нужен. И, да, у вас в вагранте железо другое, чем на той же vmware, так что привет - проблемы железа вы не отловите... Поэтому ценности в нем гонять софт не так много, на самом деле, как может показаться на первый взгляд
А ну, если дело дошло до проблем с железом, то да. Там может оказаться, что и виртаулки мало, и нужно вот прям физическую железку. В конце концов SaaS мир не ограничивается и понятия прода может не быть вовсе.
А я все-таки имел ввиду класс проблем попроще - проблем связанных с ядром. Для них и меры можно попроще использовать.
Еще пример - это запуск некоторых windows приложений на линуксе/маке приходится делать через parallels.
Я всё же задавал вопрос в контексте статьи про Vagrant и кубер, а не вообще зачем нужны виртуалки :)
Если же мы говорим про разработку, то если вы пишете софт который хоть как-то зависит от ядра, то рано или поздно вы начнете встречать проблемы, которые воспроизводятся только на конкретных версиях ядра. И тут без виртуалок было бы супер больно это фиксить.
При чём тут кубер, который оркестрирует контейнеры?
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
Upd. Увидел ваш коммент ниже. Кажется, что в данном треде у нас имело место банальное недопонимание. В целом, все кажется согласны с утверждением, что vagrant для запуска кубера просто напросто не нужен.
Весь тред пошел с вашего заявления
Vagrant это legacy, потому что это виртуалки, а они, как известно, потребляют значительно больше системных ресурсов, чем контейнеры и поднимаются медленнее.
Заметьте, в утверждении ни слова о кубере. Я пытаюсь донести мысль, что ни вагрант, ни виртуалки не являются легаси, и что у них и у контейнеров хоть и пересекающиеся, но все же разные области применения.
Перечитав свой коммент понял, что как-то он слишком в общем про виртуалки получился, а не про в контексте работы Vagrant + K8s :)
Повторюсь, что конечно на винде и маке докер под капотом использует виртуализацию, но Vagrant тут совершенно лишний, т.к. есть, например, docker desktop.
Поднять 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
Вроде ничего сложного.
Как настроить Kubernetes кластер на Vagrant VM