Как развернуть kubernetes локально windows

Обновлено: 05.07.2024

Сегодня открываю новый цикл статей, которые будут иметь непосредственное отношение к Devops и всему, что с этим связано. Начну с того, что расскажу, как установить и запустить кластер Kubernetes на собственном железе. Буду использовать установку через Kubespray с использованием ingress контроллера в кластере.

Цели статьи

Коротко рассказать о том, что такое Kubernetes и для чего он нужен.
Перечислить основные системные требования для разворачивания своего кластера Kubernetes.
Выполнить непосредственно установку кластера на свое железо.

Введение

Хочу сразу обратить внимание на важный момент. У меня нет опыта промышленной эксплуатации кластера Kubernetes. Я нахожусь в состоянии обучения и исследования этого инструмента. Я прошел обучение Слёрм, это дало базовые знания и понимание принципов работы. Дальше стал разворачивать свои кластера и исследовать их. Изначально я не хотел писать статьи по этой теме до тех пор, пока не накопится достаточного опыта, но сейчас поменял свое мнение.

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

Могу однозначно сказать, что если у вас есть необходимость в продакшене использовать Kubernetes, не тяните время и не откладывайте. Идите учиться на курсы. Самостоятельно вы не освоите в достаточном объеме материал, чтобы можно было переносить рабочую нагрузку в свой кластер. Очень много нюансов и подводных камней. Вы потратите больше времени, нервов и денег на самостоятельное освоение, если будете сами все с нуля изучать.

Лично у меня сейчас нет цели становиться администратором Kubernetes. Мой формат занятости не подразумевает обслуживание таких крупных систем и в планах этого тоже пока нет. Мне просто любопытно его исследовать, узнавать что-то новое, поэтому я этим занимаюсь. Знания карман не тянут, особенно современные и востребованные.

Kubernetes простыми словами

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

В Kubernetes все крутится вокруг докер контейнеров. Это инструмент для их запуска, поднятия в случае падения, распределения ресурсов и т.д. Под капотом никакой магии. Там обычный docker, iptables, etcd, nat, dns, ceph, nfs и т.д. Просто все собрано в одном месте для решения конкретных задач. Таким образом, для эффективного управления кластером кубера нужен хороший бэкграунд классического linux админа. Без этих знаний будет трудно.

Есть много способов разворачивания кластера, так как он модульный. Не всем и не всегда нужны все его компоненты. К примеру, есть ingress контроллер для распределения входящих запросов по сервисам. Под капотом там обычный nginx в режиме proxy_pass, интегрированный в инфраструктуру кластера. Реализация сети в кластере тоже может быть разной - на уровне l2 или l3 с помощью тех или иных технологий. То же самое с файловыми хранилищами - локальные хранилища серверов, nfs хранилища, ceph и т.д.

В зависимости от того, какой функционал вам нужен, выбирается способ установки кластера kubernetes. Мы можете его установить полностью вручную, добавляя один компонент за другим. А можно использовать готовое средство, к примеру Kubespray, где весь необходимый для установки функционал реализуется с помощью ролей ansible. На Слёрме нас учили ставить кластер, используя свой форк компании southbridge. Они там немного изменили функционал под свои потребности. Я ставил и по их форку, и по оригинальному Kubespray. Основное отличие от классического Kubespray в том, что не используется kubeadm и сертификаты для общения компонентов кластера сразу выпускаются то ли на 10, то ли на 100 лет, не помню точно. В Kubespray сертификаты выписываются только на год и надо отдельно следить за их актуальности и своевременно обновлять.

Подведу итог о том, что же такое Kubernetes. Кубернетис - средство оркестрации (управления) контейнерами Docker. Это удобный инструмент для их автоматического запуска, выделения ресурсов, контроля состояния, обновления.

Кому нужен Kubernetes

Теперь порассуждаем о том, кому может пригодиться Kubernetes. В первую очередь это крупные компании со своими разработками в ИТ и командами программистов, для которых нужна большая производственная среда. Кластер Кубера добавляет серьезные накладные расходы на свое содержание, поэтому в небольших проектах выгоды от него не будет. Нет смысла объединить 5 маленьких виртуалок в кластер и эксплуатировать его. Если только для тестов. Или если вы точно уверены, что у проекта будет серьезный рост в ближайшее время. Под небольшую структуру и нагрузки лучше подыскать решения попроще, чем кубернетис.

Kubernetes накладывает серьезные требования к приложениям, которые в нем работают. Они должны быть изначально спроектированы и написаны по принципу микросервисов. У вас не получится взять и перенести в кластер сайт на wordpress или bitrix, даже если они очень большие и нагруженные. Вернее, перенести то вы их сможете, но вряд ли вам от этого будет проще и удобнее. Основное преимущество кластера - гибкость в разработке, деплое приложения, а так же в распределении ресурсов.

Примерная схема работы с кластером кубернетис на пальцах будет такая:

Разработчики какого-то одного сервиса проекта выпускают обновление, запушив его в репозиторий.
Система сборки формирует докер контейнер с этими изменениями и кладет в registry.
Контейнер уезжает на тесты и если все в порядке, выкатывается в продакшн кластер kubernetes.

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

Теперь смотрим на Bitrix или WordPress. Они являются монолитными приложениями, написанными на php с использованием базы Mysql. В них нет микросервисов. Вам нужно либо как-то разбивать их на части, либо постоянно выкатывать все целиком. Но в этом случае смысл кластера кубернетис теряется, его гибкость настроек и выделения ресурсов под потребности не используются. Вам проще поставить обычный балансер на вход, сделать несколько нод для обработки php и за ними кластер БД.

Резюмируя все сказанное. Kubernetes - нишевое решение под конкретные проекты. Оно подходит далеко не всем и не надо его пихать туда, где от него не будет толку. Думаю, находятся люди, которые так делают. Сужу по тому, что мне в комментариях к некоторым статьям, например, про установку zabbix, пишут, а почему вы не в докере его ставите. Люди не понимают, что такое докер, для чего он нужен и какие проблемы решает. Смысла в использовании zabbix в docker нет никакого вообще. Docker создан для удобной разработки и деплоя приложений в продакшн. Этакий расширенный пакетный менеджер. В первую очередь он инструмент разработчиков.

Системные требования

Как таковых жестких системных требований у Kubernetes нет. Он с очень маленьких установок расширяется до огромных кластеров. Для того, чтобы его просто попробовать и посмотреть, достаточно следующих виртуальных машин:

2-3 мастер ноды с 2 cpu и 4 gb ram
ingress нода с 1 cpu и 2 gb ram
рабочие ноды для контейнеров от 2 cpu и 4 gb ram

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

Название	IP	CPU	RAM	HDD
kub-master-1	10.1.4.36	2	4G	50G
kub-master-2	10.1.4.37	2	4G	50G
kub-master-3	10.1.4.38	2	4G	50G
kub-ingress-1	10.1.4.39	2	4G	50G
kub-node-1	10.1.4.32	2	4G	50G
kub-node-2	10.1.4.33	2	4G	50G

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

По гипервизорам виртуальные машины распределил следующим образом.

Упомяну про еще одну рекомендацию. Мастер ноды с etcd дают приличную нагрузку на диск. Их рекомендуется размещать на быстрых ssd дисках. Чем больше кластер - тем больше нагрузка. В наших тестах сойдет и hdd диск под мастер. Но если будете использовать в продакшене с учетом расширения и роста, лучше сразу планируйте быстрые диски под мастера.

Подготовка к установке

Кластер Kubernetes я буду разворачивать на виртуальных машинах Centos 7. На них она установлена в минимальной конфигурации. Напоминаю, что установка будет проходить с помощью Kubespray. Я рекомендую склонировать к себе репозиторий, чтобы у вас сохранилась версия kubespray, с которой вы устанавливали кластер. Это позволит без проблем создавать копию кластера для тестов, дебага, обновления и т.д. Я для этого использую свой сервер Gitlab. Рекомендую озаботиться его наличием. Он нам очень пригодится и дальше в процессе знакомства и изучения кластера.

На виртуальных машинах нужно отключить следующие сущности:

SELinux (привет любителям безопасности, считающим, что selinux отключают только дилетанты).
Swap.
FirewallD, либо любой другой firewall.

На все сервера должен быть разрешен доступ пользователя root по ssh с одним и тем же паролем.

Установка кластера Kubernetes

Я буду устанавливать кластер Kubernetes с сервера kub-master-1. Установим на него некоторые пакеты, которые нам понадобятся в дальнейшем.

Теперь клонируем себе локально репозиторий kubespray.

Устанавливаем зависимости kubespray через pip, которые перечислены в файле requirements.txt.

Теперь нам нужно заполнить инвентарь ansible, исходя из нашего набора серверов. Для этого скопируем стандартный инвентарь sample и будем редактировать его.

Приводим файл inventory.ini к следующему виду.

В принципе, тут все понятно, если вы знакомы с работой ansible. Мы распределили хосты по ролям. Обращаю внимание, что сервер ingress по сути является обычной нодой, только с дополнительным функционалом, поэтому он присутствует в том числе в группе kube-node. Далее вы можете его использовать и как ingress, и как обычную ноду одновременно.

Теперь редактируем некоторые параметры. Для удобства восприятия, я их прокомментировал прямо тут, рядом со значениями. Переносить комментарии в реальные конфиги не надо. Они только для инфомрации на сайте. Начнем с файла

/kubespray/inventory/dev/group_vars/all/all.yml. Добавляем туда параметры:

Я буду использовать сетевой плагин flannel и iptables. Это хорошо проверенное и полностью готовое к production решение. Никаких особых настроек не требует, кроме пары параметров. Добавляем их в файл

В данном случае 10\\.1\\.4\\.\\d это регулярное выражение, которое описывает подсеть 10.1.4.0/24, в которой у меня размещены виртуальные машины под кластер. Если у вас подсеть машин для кластера, к примеру, 192.168.55.0, то регулярка будет 192\\.168\\.55\\.\\d

Теперь настроим ingress. Добавляем параметры в

/kubespray/inventory/dev/group_vars/kube-ingress.yml и добавляем параметры:

Трудно кратко и понятно описать настройки ingress, так как тут используются не тривиальные возможности kubernetes в виде taints и tolerations. Общий смысл в том, что мы задаем метку для ingress и поведение на основе этой метки. На ноды в группе kube-ingress ставится ограничение NoSchedule (не распределять поды на ноду) с помощью taints. Это ограничение могут преодолевать только только те, у кого в tolerations прописана метка ingress. Таким образом, на нодах ingress, кроме самого ингресса ничего запускаться не будет.

Вот и все. Мы готовы к тому, чтобы начать установку кластера Kubernetes. Запускаем ее с помощью ansible-playbook. Рекмоендую делать это в screen, чтобы не прерывался процесс из-за обрыва связи.

Процесс обычно длится 15-20 минут. У меня сервера старые, на hdd, длилось 30 минут. В конце вы должны увидеть примерно такую картину.

Ошибок быть не должно. Если есть ошибки, внимательно ищите их в выводе ansible и исправляйте. Основные ошибки возникают из-за неправильно заполненного инвентаря, из-за неправильной маски ip в свойствах flannel, из-за ошибок загрузки докер образов в процессе установки. После исправления ошибки можно запускать этот же плейбкук снова. Чаще всего все будет нормально донастроено.

Проверить состояние кластера можно командой:

Для сервера ingress смотрите сами, хотите вы на него дополнительно вешать роль node или оставите только в качестве ingress контроллера. В продакшене лучше оставить его отдельно. Если у вас тестовый кластер, то можете объединить эти роли на одном сервере.

Если же вы захотите убрать какую-то роль, то команда будет такой.

Мы убрали роль node на сервере kub-ingress-1. Проверяем снова состояние кластера.

Посмотреть подробную информацию о ноде можно командой.

Рекомендую запомнить эту команду. Она очень пригодится в процессе эксплуатации кластера и дебага. Особое внимание на раздел Events. Именно он будет очень полезен при разборе ошибок на нодах.

Посмотрим список всех запущенных подов.

Они все должны быть в состоянии Running. Если это не так, то у вас какие-то ошибки, с которыми надо разбираться. В общем случае ошибок быть не должно, если вы все сделали правильно на моменте подготовки инвентаря.

На этом непосредственно установка кластера Kubernetes закончена. Он готов к эксплуатации. Если вы только знакомитесь с ним, то, думаю, вам совсем не понятно, что делать дальше и как его эксплуатировать. Об этом будут мои последующие статьи. Следите за обновлениями.

Проблема с сертификатами

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

Я до конца не понял и не проработал вопрос обновления сертификатов, но это нужно будет сделать. Пока просто покажу, как за ними можно следить.

Сертификат api-server, порт 6443

Сертификат controller manager, порт 10257.

Сертификат scheduler, порт 10259.

Это все разные сертификаты и они выпущены на год. Их надо будет не забыть обновить. А вот сертификат для etcd. Он выпущен на 100 лет.

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

Заключение

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

В планах и git, и ansible, и prometeus, и teamcity, и кластер elasticsearch. К сожалению, доход с сайта не оправдывает временных затрат на написание статей, поэтому приходится писать их либо редко, либо поверхностно. Основное время уходит на текущие задачи по настройке и сопровождению.

Изучение Docker и Kubernetes в Windows сделает невозможным запуск. По крайней мере, установка этих программ не является легкой задачей. На самом деле, вы должны быть достаточно знакомы с Docker и Kubernetes, чтобы знать, как выбирать опции параметров для включения во время установки.
Но не волнуйся!
Эта статья для студентов, которые только начали работать с контейнерами и Kubernetes на Winodws.
Вы узнаете, как сделать правильный выбор для построения среды разработки контейнеров в Windows. Давайте начнем с докера.

Вы используете Windows 10 Home edition? Вы не сможете запустить Docker для Windows

Когда разработчики Docker решили внедрить Docker на Winodows, они выбрали Hyper-V в качестве технологии виртуализации. Это преимущество очень очевидно: отличная производительность и собственный гипервизор.
К сожалению, не все версии Windows поддерживают Hyper-V.
Если вы используете домашнюю версию Windows 10 или студенческую версию, то вы - победитель. Вы не сможете установить и запустить Docker для Windows.
Но не разочаровывайся.
У вас есть много доступных альтернатив Docker Machine, таких как Docker toolbox или minikube.
Docker Machine работает просто: для вас установлена виртуальная машина с Linux и Docker. Вы можете подключиться к Docker deamon на виртуальной машине с вашего хоста.
Minikube - это, пожалуй, одна из самых интересных виртуальных машин на основе Docker Machine - в ней можно запускать кластеры Kubernetes.
Фактически, minikube - это виртуальная машина с Docker и Kubernetes. Обычно он используется для запуска Kubernetes самостоятельно, но вы также можете использовать его для запуска контейнеров Docker.
Возможно, у вас нет скорости Docker для Windows, но, в конце концов, вам не нужен Hyper-V для создания и запуска контейнеров.

В Windows 10 Pro лучшим выбором является Docker для Windows (кроме особых случаев)

У вас установлена последняя версия Win 10 Pro, и вы можете установить Docker для Windows. У вас отличная производительность и опыт разработчика, все сделано, верно?
Ответ не обязательно!
Гипервизор, используемый Docker для Windows, довольно мощный - он относится к гипервизору типа 1. Он действительно мощный, но не может работать с гипервизором типа 2, таким как Virtualbox.
Вы не можете одновременно запускать гипервизоры типа 1 и типа 2 на одном компьютере. Другими словами, если вы запускаете Docker для Windows, вы не можете запустить виртуальную машину в VirtualBox.
Это связано с вашими настройками, и влияние может быть большим или маленьким.
Если вы полностью использовали контейнеризацию, вам не нужно беспокоиться о виртуальных машинах - устаревших вещах.
Но если вам все еще нужно использовать виртуальные машины и такие инструменты, как Vagrant, у вас могут возникнуть проблемы.
Вы можете включить или отключить гипервизор Hyper-V по своему желанию, но вам необходимо перезагрузить компьютер.
Если вы часто переключаетесь с контейнера на виртуальную машину, может быть удобнее использовать мини-куб. Нет необходимости перезагружать компьютер при переключении с контейнера на виртуальную машину. Недостатком является то, что вы не можете получить более высокую производительность и лучший опыт.
Наконец, если вы хотите запустить контейнер Windows - базовый образ - это контейнер из Windows-Docker для Windows - единственный вариант. Вы можете использовать только Windows 10 Pro или Enterprise Edition.

Запустите локальный кластер Kubernetes

Если вы хотите запустить местный Kubernetes, то вы должны рассмотреть мини-куб.
Minikube - это виртуальная машина со встроенным Linux (Buildroot) и предварительно установленным демоном Docker.
Это минимальная и полная среда Kubernetes.
Виртуальная машина Minikube может работать через VirtualBox или Hyper-V (конечно, есть и другие варианты). Если у вас уже есть Hyper-V, вы также будете использовать его для запуска Docker и Minikube.
Конечно, не имеет значения, если вы не можете запустить Hyper-V, вы можете использовать VirtualBox для достижения той же функции.
Есть много вариантов и компромиссов, на следующем графике перечислены некоторые из них:
посылка

Вы можете скачать и установить Docker для Windows, Docker Toolbox, VirtualBox, kubectl, Docker CLI и т. Д. С официального сайта, но это довольно хлопотно.
Вам нужно перейти на официальный сайт, чтобы найти правильный адрес загрузки, выбрать правильную версию, загрузить и установить, и, наконец, добавить его в свой путь.
Это, конечно, возможно, но я уверен, что вы предпочитаете тратить свое время на программирование, а не на скачивание и установку пакетов программного обеспечения с веб-сайтов.
Используйте шоколад
Chocolatey - менеджер пакетов для Widnows. Вы говорите пакет, который он хочет установить, и он установит его для вас. Вы производите установку программного обеспечения на стороне.
Установить Chocolatey просто. Вы можете найти шаги на его официальном сайте [1]. Короче, всего несколько шагов:
1. Запустите cmd.exe от имени администратора.
2. Выполните следующую команду:

3. Перезагрузите cmd.exe
Если установка прошла успешно, вы можете выполнить поиск пакета:

Давайте попробуем и установим Cmder, стильную оболочку для Windows:

Chocolatey будет установлен в C: \ tools. Если вы хотите использовать Cinder для следующих упражнений, вы можете запустить его как администратор:

Выглядит хорошо!

1. Установите Docker и Kubernetes на Windows 10 Pro

Установить докер
Установите Docker для Windows:

Перезагрузите компьютер. Docker спросит, хотите ли вы включить Hyper-V.

Выберите Да.
Вы должны знать, что Docker должен включать аппаратные расширения виртуализации VT-X / AMD-v для запуска контейнеров. Вам необходимо настроить его в BIOS при перезагрузке компьютера.
Вы можете использовать команду systeminfo, чтобы проверить, включен ли VT-x / AMD-v.
Если вы не уверены, включен ли VT-x / AMD-v, не беспокойтесь. Если у вас его нет, Docker сообщит об ошибке:
Hardware assisted virtualization and data execution protection must be enabled in the BIOS.

Другая распространенная проблема заключается в том, что Hyper-V не включен, поэтому вы увидите следующую ошибку:

Вы должны включить Hyper-V. Откройте новую командную строку от имени администратора и введите:

После перезагрузки компьютера Docker сможет запуститься.
Но как ты узнал, что Docker запустился?
Откройте командную строку:

Если все нормально, то вы увидите пустой список (список запущенных контейнеров).
Если Docker deamon не запущен, вы можете столкнуться со следующей ошибкой:

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

Установите Minikube на Hyper-V

Перед запуском кластера вы должны сначала создать внешний сетевой коммутатор.
На первом этапе вы должны сначала проверить сетевой адаптер вашего компьютера.
Вы должны игнорировать виртуальную сетевую карту и сосредоточиться на реальной активной физической сетевой карте, такой как Ethernet или WiFi.
Выберите физический сетевой адаптер для совместного использования сетевого подключения с виртуальным коммутатором.
Чтобы просмотреть текущий сетевой адаптер, вы можете использовать командлет Get-NetAdapter в PowerShell.
Нажмите значок Windows в левом нижнем углу и введите PowerShell, чтобы открыть его:
Введите следующую команду, чтобы получить список всех адаптеров:

Если вы все еще не знаете, какой из них выбрать, выберите тот, который находится в состоянии «Вверх».
После того, как вы выбрали адаптер, вы можете начать создавать внешний виртуальный коммутатор:

Обратите внимание: --vm-driver = hyperv --hyperv-virtual-switch = minikube требуется только для первого запуска. Если вы хотите изменить драйвер или память, то вам нужно выполнить minkube destroy и заново создать его с новой конфигурацией.
Если мини-куб не запускается, вы можете выполнить отладку с помощью следующей команды:

Дополнительные журналы вывода могут помочь вам быстро устранить неполадки. Я столкнулся со следующими проблемами:
E0427 09:19:10.114873 10012 start.go:159] Error starting host: Error starting stopped host: exit status 1.
Я ничего не вижу Я открыл подробный вывод журнала, и ошибка стала очевидной:

Недостаточно памяти!
В это время вы можете увидеть, если установка прошла успешно. В командной строке введите:

Вы увидите узел, отображаемый в Kubernetes.
Запустите виртуальную машину в VirtualBox
Поскольку вы включили Hyper-V на устройстве, вы больше не можете запускать виртуальную машину через virtualbox. Если вы принудительно включите vm, вы увидите следующую ошибку:

Если вы хотите использовать гипервизор типа 2, такой как VirtualBox, вы должны сначала остановить Hyper-V и перезагрузить компьютер.
Откройте командную строку от имени администратора:

После перезагрузки компьютера вы можете использовать VirtualBox в обычном режиме.
Если вы хотите снова использовать Docker и minkube, вам нужно снова открыть Hyper-V и перезагрузить компьютер.
Откройте командную строку как администратор и введите:

Перезапустите, чтобы вы могли развернуть контейнер в Kubernetes.
Пожалуйста, перейдите к тестированию установки Docker [2].

2. Установите Docker и Kubernetes на версию Win 10 Home.

Если вы используете домашнюю или студенческую версию Windows 10, вам может не потребоваться установка инструментов Docker Machine (таких как Docker Toolbox).
Вы должны использовать minikube в качестве удаленного Docker deamon и локального кластера Kubernetes.
Вы можете скачать и установить миникуб:

После завершения установки вы можете запустить:

Эта команда загрузит ISO для использования VirtualBox, а затем запустит виртуальную машину. После запуска вы можете проверить состояние кластера:

Смотрите узел в списке.
Чтобы подключиться к удаленному Docker deamon, вы должны установить Docker клиент:

Вы можете подключиться к удаленному Docker-демону в minkube:

Примечание. Каждый раз, когда вы открываете новое окно командной строки, вам нужна указанная выше команда. Простой способ напомнить себе - это нажать на мини-куб docker-env.
Если соединение установлено успешно, вы можете перечислить текущие запущенные контейнеры:

Docker daemon - вы можете понимать это как сервер API. Вы отправляете команды в его API, а Docker получает и выполняет команды.

Docker CLI - отправляет команды в исполняемый файл API-интерфейса Daemon.

Большую часть времени вы будете взаимодействовать только с интерфейсом командной строки Docker, вы не увидите демона Docker.
Так почему же есть клиенты и серверы? Почему бы не использовать файл?
Это все для гибкости.
Когда вы запускаете Docker для Windows, интерфейс командной строки Docker подключается к локальному демону Docker.

Но иногда у вас нет демона локально.
Может быть, вам нужно построить контейнер Docker на удаленной машине.
Возможно, у вас нет среды Hyper-V, и ваш демон Docker установлен в виртуальной машине внутри VirtualBox.
Особенно, если вы работаете в миникубе.
Интерфейс командной строки Docker подключится к удаленному демону Docker, развернутому на виртуальной машине minikube.

Когда ваш контейнер работает на удаленном Docker-демоне, вам нужно настроить привязку порта. В Docker для Windows вы можете привязать порт контейнера к 8080:

Если вы хотите увидеть запущенный контейнер, вам нужно получить доступ к компьютеру, на котором расположен демон Docker. Вы можете найти IP с помощью следующей команды:

Протестируйте вашу установку Docker

Вы установили Docker, как узнать, работает ли он правильно?
Зайдите в терминал и введите:

Проверьте вашу кластерную установку Kubernetes

Пришло время проверить ваш местный кластер Kubernetes. В этой части вы развернете панель Smashing.io.

Развернуть Smashing в Kubernetes
Вы можете развернуть с помощью следующей команды:

Как только Kubernetes закончит установку контейнера, вы можете проверить статус выполнения:

Открытая панель
Вы можете выставить свой развернутый сервер:

Вы можете открыть панель через браузер:

Таким образом, вы можете получить доступ к панели изнутри Kubernetes! Да здравствует!
Птичьего полета из Кубернетеса

Minikube поставляется с некоторыми хорошими вещами.
Вы можете получить доступ к официальной панели:

Отсюда вы можете просмотреть информацию о вашем кластере и развернуть приложения.

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

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

Решения для запуска на локальной машине

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

Вам следует выбрать запуск на локальной машине, если вы:

Пробуете или начинаете работу с Kubernetes
Локально разрабатываете и тестируете кластер

Управляемые решения

Управляемые решения позволяют надёжно и удобно создавать и поддерживать кластеры Kubernetes. Они настраивают и управляют кластером самостоятельно, не требуя ручного вмешательства.

Вам следует выбрать управляемое решение, если вы:

Хотите получить полностью самоуправляемое решение
Хотите сконцентрироваться на разработке собственных приложений или сервисов
Хотите получить высокую доступность, но у вас нет выделенной команды по обеспечению надёжности приложения (SRE).
Не имеете ресурсов для размещения и мониторинга собственных кластеров

Облачные решения "под ключ"

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

Вам следует выбрать облачное решение "под ключ", если вы:

Хотите получить больший контроль над кластерами, чем позволяют размещённые решения
Хотите получить больше контроля над операциями

Местное резервное решение "под ключ"

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

Вам следует выбрать местное резервное решение "под ключ", если:

Вы хотите развернуть кластер в приватной облачной сети
У вас есть выделенная команда SRE-специалистов
У вас есть ресурсы для размещения и мониторинга собственных кластеров

Пользовательские решения

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

Что дальше

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

Minikube — это инструмент, позволяющий легко запускать Kubernetes на локальной машине. Для тех, кто хочет попробовать Kubernetes или рассмотреть возможность его использования в повседневной разработке, Minikube станет отличным вариантом, потому что он запускает одноузловой кластер Kubernetes внутри виртуальной машины (VM) на компьютере пользователя.

Возможности Minikube

Minikube поддерживает следующие возможности Kubernetes:

DNS
Сервисы NodePort
Словари конфигурации (ConfigMaps) и секреты (Secrets)
Панель управления (Dashboard)
Среда выполнения контейнера: Docker, CRI-O и containerd
Поддержка CNI (Container Network Interface)
Ingress

Установка

Краткое руководство

Эта простая демонстрация поможет запустить, использовать и удалить Minikube на локальной машине. Следуйте перечисленным ниже шагам, чтобы начать знакомство с Minikube.

Запустите Minikube и создайте кластер:

Вывод будет примерно следующим:

Дополнительную информацию о запуске кластера в определенной версии Kubernetes, виртуальной машине или среде выполнения контейнера смотрите в разделе Запуск кластера.

Теперь вы можете работать со своим кластером через CLI-инструмент kubectl. Для получения дополнительной информации смотрите раздел Работа с кластером.

Вывод будет примерно следующим:

Чтобы получить доступ к объекту Deployment hello-minikube извне, создайте объект сервиса (Service):

Опция --type=NodePort определяет тип сервиса.

Вывод будет примерно следующим:

Под (Pod) hello-minikube теперь запущен, но нужно подождать, пока он начнёт функционировать, прежде чем обращаться к нему.

Проверьте, что под работает:

Если в столбце вывода STATUS выводится ContainerCreating , значит под все еще создается:

Если в столбце STATUS указано Running , то под теперь в рабочем состоянии:

Узнайте URL-адрес открытого (exposed) сервиса, чтобы просмотреть подробные сведения о сервисе:

Чтобы ознакомиться с подробной информацией о локальном кластере, скопируйте и откройте полученный из вывода команды на предыдущем шаге URL-адрес в браузере.

Вывод будет примерно следующим:

Если сервис и кластер вам больше не нужны, их можно удалить.

Удалите сервис hello-minikube :

Вывод будет примерно следующим:

Удалите развёртывание hello-minikube :

Вывод будет примерно следующим:

Остановите локальный кластер Minikube:

Вывод будет примерно следующим:

Подробности смотрите в разделе Остановка кластера.

Удалите локальный кластер Minikube:

Вывод будет примерно следующим:

Подробности смотрите в разделе Удаление кластера.

Управление кластером

Запуск кластера

Команда minikube start используется для запуска кластера. Эта команда создаёт и конфигурирует виртуальную машину, которая запускает одноузловой кластер Kubernetes. Эта команда также настраивает вашу установку kubectl для взаимодействия с этим кластером.

Если вы работаете из-под веб-прокси, вам нужно указать данные прокси в команде minikube start :

К сожалению, установка переменных окружения не cработает.

Minikube также создает контекст "minikube" и устанавливает его по умолчанию в kubectl. Чтобы вернуться к этому контексту, выполните следующую команду: kubectl config use-context minikube .

Указание версии Kubernetes

Вы можете указать используемую версию Kubernetes в Minikube, добавив параметр --kubernetes-version в команду minikube start . Например, чтобы запустить Minikube из-под версии v1.22.0, вам нужно выполнить следующую команду:

Указание драйвера виртуальной машины

Вы можете изменить драйвер виртуальной машины, добавив флаг --vm-driver=<enter_driver_name> в команду minikube start .

Тогда команда будет выглядеть так:

Minikube поддерживает следующие драйверы:

Заметка: Смотрите страницу DRIVERS для получения подробной информации о поддерживаемых драйверах и как устанавливать плагины.

virtualbox
vmwarefusion
docker (ЭКСПЕРИМЕНТАЛЬНЫЙ)
kvm2 (установка драйвера)
hyperkit (установка драйвера)
hyperv (установка драйвера) Обратите внимание, что указанный IP-адрес на этой странице является динамическим и может изменяться. Его можно получить с помощью minikube ip .
vmware (установка драйвера) (VMware unified driver)
parallels (установка драйвера)
none (Запускает компоненты Kubernetes на хосте, а не на виртуальной машине. Использование этого драйвера требует использование Linux и установленного Docker.)

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

Запуск кластера в других средах выполнения контейнеров

Вы можете запустить Minikube в следующих средах выполнения контейнеров.

Чтобы использовать containerd в качестве среды выполнения контейнера, выполните команду ниже:

Также можете использовать расширенную вариант команды:

Чтобы использовать CRI-O в качестве среды выполнения контейнера, выполните команду ниже:

Также можете использовать расширенную вариант команды:

Использование локальных образов путём повторного использования демона Docker

При использовании одной виртуальной машины для Kubernetes легко повторно использовать демон Docker, встроенный в Minikube. В этом случае нет необходимости создавать реестр Docker на вашей хост-машине и отправлять образ туда. Вместо этого вы можете создать реестр внутри того же демона Docker, который использует Minikube, что позволит ускорить локальные запуски.

Заметка: Обязательно пометьте собственным тегом Docker-образ, и затем при получении образа всегда указывайте его. Так как :latest — это тег по умолчанию, поэтому наряду с соответствующей стандартной политикой получения образа, равной Always , в конечном итоге возникнет ошибка при получении образа ( ErrImagePull ), если Docker-образ не найден в базовом реестре Docker (как правило, в DockerHub).

Для работы с Docker-демоном на вашем хосте под управлением Mac/Linux, запустите последнюю строку из вывода команды minikube docker-env .

Теперь вы можете использовать Docker в командной строке вашего хост-компьютера на Mac/Linux для взаимодействия с демоном Docker внутри виртуальной машины Minikube:

На Centos 7 Docker может возникнуть следующая ошибка:

Для исправления этой ошибки обновите файл /etc/sysconfig/docker , чтобы учитывались изменения в среде Minikube:

Конфигурация Kubernetes

Minikube имеет такую возможность как "конфигуратор" ("configurator"), позволяющая пользователям настраивать компоненты Kubernetes произвольными значениями. Чтобы использовать эту возможность, используйте флаг --extra-config в команде minikube start .

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

Этот флаг принимает строку вида component.key=value , где component — это одно из значение в приведённом ниже списка, key — ключ из структуры конфигурации, а value — значение, которое нужно установить.

Допустимые ключи можно найти в документации по componentconfigs в Kubernetes каждого компонента. Ниже вы найдете документации по каждой поддерживаемой конфигурации:

Примеры

Чтобы изменить настройку MaxPods на значение 5 в Kubelet, передайте этот флаг --extra-config=kubelet.MaxPods=5 .

Эта возможность также поддерживает вложенные структуры. Для изменения настройки LeaderElection.LeaderElect на значение true в планировщике, передайте флаг --extra-config=scheduler.LeaderElection.LeaderElect=true .

Чтобы изменить настройку AuthorizationMode в apiserver на значение RBAC , используйте флаг --extra-config=apiserver.authorization-mode=RBAC .

Остановка кластера

Команда minikube stop используется для остановки кластера. Эта команда выключает виртуальную машины Minikube, но сохраняет всё состояние кластера и данные. Повторный запуск кластера вернет его в прежнее состояние.

Удаление кластера

Команда minikube delete используется для удаления кластера. Эта команда выключает и удаляет виртуальную машину Minikube. Данные или состояние не сохраняются.

Обновление minikube

Работа с кластером

Kubectl

Команда minikube start создает контекст kubectl под именем "minikube". Этот контекст содержит конфигурацию для взаимодействия с кластером Minikube.

Minikube автоматически устанавливает этот контекст, но если вам потребуется явно использовать его в будущем, выполните команду ниже:

Либо передайте контекст при выполнении команды следующим образом: kubectl get pods --context=minikube .

Панель управления

Чтобы получить доступ к веб-панели управления Kubernetes, запустите эту команду в командной оболочке после запуска Minikube, чтобы получить адрес:

Сервисы

Чтобы получить доступ к сервису, открытой через порт узла, выполните команду в командной оболочке после запуска Minikube, чтобы получить адрес:

Организация сети

Виртуальная машина Minikube доступна только хост-системе через IP-адрес, который можно получить с помощью команды minikube ip . Вы можете использовать IP-адрес для доступа к любому сервису типа NodePort .

Чтобы определить NodePort для вашего сервиса, вы можете использовать такую команду kubectl :

Постоянные тома

Minikube поддерживает PersistentVolumes типа hostPath . Эти постоянные тома монтируются в виртуальную машину Minikube.

Виртуальная машина Minikube загружается в файловую систему tmpfs, поэтому большинство директорий не будет сохранено при перезагрузках ( minikube stop ). Однако Minikube сконфигурирован на сохранение файлов, хранящихся в перечисленных ниже директорий хоста.

/data
/var/lib/minikube
/var/lib/docker

Пример конфигурации PersistentVolume для сохранения данных в директории /data :

Смонтированные директории хоста

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

Заметка: Совместное использование директории хоста еще не реализовано в драйвере KVM.

Driver	OS	HostFolder	VM
VirtualBox	Linux	/home	/hosthome
VirtualBox	macOS	/Users	/Users
VirtualBox	Windows	C://Users	/c/Users
VMware Fusion	macOS	/Users	/mnt/hgfs/Users
Xhyve	macOS	/Users	/Users

Приватные реестры контейнеров

Для доступа к реестру приватных контейнеров, выполните шаги, описанные на этой странице.

Мы рекомендуем использовать ImagePullSecrets , но если вам нужно обратиться к нему из виртуальной машины Minikube, нужно поместить файл .dockercfg в директорию /home/docker или config.json в директорию /home/docker/.docker .

Дополнения

Для того, чтобы Minikube смог запустить или перезапустить пользовательские дополнения, поместите дополнения, которые вы хотите запускать с помощью Minikube, в директорию

/.minikube/addons . Дополнения в этой директории будут перемещены в виртуальную машину Minikube и запускаться каждый раз при запуске или перезапуске Minikube.

Minikube создаёт виртуальную машину, включающая в себя Kubernetes и демон Docker. Когда Kubernetes планирует выполнение контейнеров с использованием Docker, демону Docker может потребоваться доступ к внешней сети для получения контейнеров.

Если адрес вашей виртуальной машины 192.168.99.100, то, скорее всего, настройки прокси помешают kubectl обратиться к ней. Чтобы прокси игнорировал этот IP-адрес, нужно скорректировать настройки no_proxy следующим образом:

Известные проблемы

Функциональность, для которой требуется несколько узлов, не будет работать в Minikube.

Реализация

Minikube использует libmachine для подготовки виртуальных машин и kubeadm для инициализации кластера Kubernetes.

Для получения дополнительной информации о Minikube посмотрите статью.

Дополнительные ссылки

Цели: цели проекта Minikube смотрите в дорожной карте.
Руководство по разработке: посмотрите CONTRIBUTING.md, чтобы ознакомиться с тем, как отправлять пулрексты.
Сборка Minikube: инструкции по сборке/тестированию Minikube из исходного кода смотрите в руководстве по сборке.
Добавление новой зависимости: инструкции по добавлению новой зависимости в Minikube смотрите в руководстве по добавлению зависимостей.
Добавление нового дополнения: инструкции по добавлению нового дополнения для Minikube смотрите в руководстве по добавлению дополнений.
MicroK8: пользователи Linux, которые не хотят использовать виртуальную машину, могут в качестве альтернативы посмотреть в сторону MicroK8s.

Сообщество

Kind — это инструмент для запуска локальных кластеров Kubernetes с помощью "узлов" контейнера Docker.

Если вы ещё не сталкивались с платформой Kubernetes, но уже работали с Docker, то эта инструкция вам точно пригодится. Мы кратко поговорим о развёртывании кластера для разработки и рассмотрим набор сущностей Kubernetes, необходимых для развёртывания приложения: deployment и service.

Главное преимущество Kubernetes — однородность среды, где запускается приложение. Поэтому инструкцию можно будет использовать для развёртывания в локальном или production-кластере. А ещё вы сможете повторить это в своих кластерах, используя те же конфиг-файлы.

Утилита для управления Kubernetes

Для управления Kubernetes используется утилита kubectl. Перед началом всех следующих операций необходимо установить её на компьютер. Как это сделать, смотрите здесь.

Варианты развёртывания Kubernetes

Развёртывание нового production-кластера Kubernetes — трудоёмкий процесс, который может занять несколько дней. А его обслуживание требует от системных администраторов и DevOps’ов определённых компетенций. Сегодня многие облачные провайдеры предоставляют Kubernetes как сервис, позволяющий за считаные минуты развернуть «боевой» кластер. Кроме того, сообщество Kubernetes подготовило ряд решений для упрощённого развёртывания кластера вне облачной инфраструктуры. Самым популярным является Kubespray.

Но для разработки и тестирования приложений намного удобнее, чтобы каждому сотруднику был доступен свой локальный кластер Kubernetes. Одно из решений, позволяющих развернуть готовый кластер для разработки, — это Minikube.

Настройка Minikube

Для работы Minikube ваш компьютер должен поддерживать виртуализацию. Не переживайте — у большинства современных машин с этим всё в порядке.

Подробно о том, как установить Minikube, можно узнать на официальном сайте Kubernetes.

Создание пространства имён (Namespace)

Процесс развёртывания приложения представляет собой настройку конфигурационных файлов Kubernetes. У них единый стандарт и формат Yaml.

У Kubernetes есть встроенный механизм для разделения доступов и удобного управления множеством приложений — namespace. Это пространство имён. Каждому такому пространству принадлежит набор приложений с их зависимостями (хранилище, секреты, настройки сети и другое).

Перед развёртыванием приложения нужно создать namespace, которое описывается следующей конфигурацией:

kind: Namespace

apiVersion: v1

metadata:

name: test

Сохраните её в файл с каким-нибудь простым названием. Например, 01-namespace.yaml.

Для применения конфигурации нужно выполнить команду kubectl apply -f 01-namespace.yaml. После этого будет создано namespace с названием test. Это название нужно будет использовать в конфигурациях ниже. А чтобы посмотреть список namespace, можно использовать команду kubectl get ns.

Разворачиваем первое приложение

Чтобы развернуть приложение в Kubernetes, у него должен быть собранный и загруженный в репозиторий Docker-контейнер.

Базовой единицей приложения в Kubernetes служит Pod (под), который представляет собой набор из одного и более контейнеров Docker. Развернуть один под можно, используя такую конфигурацию:

kind: Pod

apiVersion: v1

metadata:

name: mypod

namespace: test

containers:

- name: mypod

image: someimage:1.0.0

После применения конфигурации будет создан под с одним контейнером (с образом someimage:1.0.0) в пространстве имён test. Вывести список всех подов можно командой kubectl get pods -n test.

Настраиваем управление подами

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

В Kubernetes существует несколько систем управления подами. Самая популярная из них — Deployment. Её можно настроить через Yaml-конфиг:

apiVersion: apps/v1

kind: Deployment

metadata:

name: mydeployment

namespace: test

selector:

matchLabels:

app: myapp

replicas: 3

template:

metadata:

labels:

app: myapp

containers:

- name: mypod

image: someimage:1.0.0

После применения будет создан deployment, который автоматически развернёт и поддержит три реплики нашего контейнера.

Чтобы Kubernetes понимал, как соотносятся поды и deployment, используется система меток (label). Для этого в секции spec указывается селектор, а в template.metadata прописываются метки самого пода. Секция template при этом содержит ту же информацию, что и ранее настроенный под.

Настройка сервисов

Для многих приложений требуется доступ извне. Чтобы настроить его, нужно создать новую сущность Kubernetes — сервис.

Есть несколько типов сервисов Kubernetes, но нам лучше всех подойдёт Nodeport. Для его развёртывания можно использовать такую конфигурацию:

apiVersion: v1

kind: Service

metadata:

name: myservice

namespace: test

type: NodePort

selector:

app: myapp

- protocol: TCP

port: 80

targetPort: 80

После этого будет создан сервис с названием myserivce, который указывает 80 порт подов с метками app: myapp. В секции ports есть поля port и targetPort. Первый служит для назначения порта в сети Kubernetes, а второй — для указания порта, на который контейнер получает входящие запросы.

Особенность сервиса Nodeport в том, что после его создания Kubernetes открывает определённый порт на всех машинах, на которых он развёрнут. Приложение становится доступным по этому порту.

Если кластер развёрнут в Minikube, он находится на виртуальных машинах. Чтобы открыть порт, там требуются дополнительные действия. В Minikube есть специальная команда, которая выполняет их и открывает приложение в браузере, автоматически подставляя назначенный порт:

minikube service myservice -n test

Итог и за кадром

Если вы следовали инструкции и всё сделали правильно, теперь у вас развёрнуто приложение на Kubernetes с несколькими репликами.

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

настройка постоянного хранилища;

настройка хранения секретов Kubernetes (паролей, ключей API и другого);

обеспечение надёжности в критических ситуациях (например, при выходе из строя физической машины);

межконтейнерное взаимодействие внутри сети Kubernetes (например, коммуникации приложения с базой);

настройка сертификатов SSL и доступ к приложению по стандартным портам 80 и 443.

Узнайте больше о тонкостях платформы на нашем курсе Kubernetes для разработчиков.

Читайте также: