Home » Devops » Kubernetes — установка, что такое и для чего нужен

Kubernetes — установка, что такое и для чего нужен

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

Теоретический курс по основам сетевых технологий. Позволит системным администраторам упорядочить и восполнить пробелы в знаниях. Цена очень доступная, есть бесплатный доступ. Все подробности по . Можно пройти тест на знание сетей, бесплатно и без регистрации.

Цели статьи

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

Введение

Хочу сразу обратить внимание на важный момент. У меня нет опыта промышленной эксплуатации кластера 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, даже если они очень большие и нагруженные. Вернее, перенести то вы их сможете, но вряд ли вам от этого будет проще и удобнее. Основное преимущество кластера — гибкость в разработке, деплое приложения, а так же в распределении ресурсов.

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

  1. Разработчики какого-то одного сервиса проекта выпускают обновление, запушив его в репозиторий.
  2. Система сборки формирует докер контейнер с этими изменениями и кладет в registry.
  3. Контейнер уезжает на тесты и если все в порядке, выкатывается в продакшн кластер 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

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

НазваниеIPCPURAMHDD
kub-master-110.1.4.3624G50G
kub-master-210.1.4.3724G50G
kub-master-310.1.4.3824G50G
kub-ingress-110.1.4.3924G50G
kub-node-110.1.4.3224G50G
kub-node-210.1.4.3324G50G

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

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

Виртуальные машины кластера Kubernetes Виртуальные машины кластера Kubernetes

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

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

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

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

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

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

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

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

# yum install mc epel-release 
# yum install wget curl git screen python-pip sshpass

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

# cd ~
# git clone https://github.com/kubernetes-sigs/kubespray

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

# cd kubespray
# pip install -r requirements.txt

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

# cp -R ~/kubespray/inventory/sample ~/kubespray/inventory/dev

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

kub-master-1 ansible_host=10.1.4.36 ip=10.1.4.36
kub-master-2 ansible_host=10.1.4.37 ip=10.1.4.37
kub-master-3 ansible_host=10.1.4.38 ip=10.1.4.38
kub-ingress-1 ansible_host=10.1.4.39 ip=10.1.4.39
kub-node-1 ansible_host=10.1.4.32 ip=10.1.4.32
kub-node-2 ansible_host=10.1.4.33 ip=10.1.4.33

[kube-master]
kub-master-1
kub-master-2
kub-master-3

[etcd]
kub-master-1
kub-master-2
kub-master-3

[kube-node]
kub-node-1
kub-node-2
kub-ingress-1

[kube-ingress]
kub-ingress-1

[k8s-cluster:children]
kube-master
kube-node

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

Теперь редактируем некоторые параметры. Для удобства восприятия, я их прокомментировал прямо тут, рядом со значениями. Переносить комментарии в реальные конфиги не надо. Они только для инфомрации на сайте. Начнем с файла ~/kubespray/inventory/dev/group_vars/all/all.yml. Добавляем туда параметры:

kubelet_load_modules: true # автоматом загружает модули в ядро системы, не спрашивая админа сервера
kube_read_only_port: 10255 # порт для мониторинга кублетов, нужен, к примеру, для prometeus

В файл ~/kubespray/inventory/dev/group_vars/all/docker.yml добавляем:

docker_storage_options: -s overlay2 # использует сторейдж overlay2 для докера

В файл ~/kubespray/inventory/dev/group_vars/etcd.yml добавляем:

etcd_memory_limit: 0 # дефолтного ограничения в 512 мб может не хватать в больших кластерах, надо либо увеличить значение, либо отключить ограничение

В файл ~/kubespray/inventory/dev/group_vars/k8s-cluster/k8s-cluster.yml добавляем:

kube_network_plugin: flannel
kube_proxy_mode: iptables
kubeconfig_localhost: true # устанавливаем локально инструменты для управления кластером

Я буду использовать сетевой плагин flannel и iptables. Это хорошо проверенное и полностью готовое к production решение. Никаких особых настроек не требует, кроме пары параметров. Добавляем их в файл ~/kubespray/inventory/dev/group_vars/k8s-cluster/k8s-net-flannel.yml.

flannel_interface_regexp: '10\\.1\\.4\\.\\d{1,3}'
flannel_backend_type: "host-gw"

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

Теперь настроим ingress. Добавляем параметры в ~/kubespray/inventory/dev/group_vars/k8s-cluster/addons.yml.

ingress_nginx_enabled: true

ingress_nginx_nodeselector:
  node-role.kubernetes.io/ingress: "true" # указываем, какая метка должна быть у ноды, чтобы туда установился ingress

ingress_nginx_tolerations:
  - key: "node-role.kubernetes.io/ingress"
    operator: "Exists"

ingress_nginx_configmap:
  server-tokens: "False"
  proxy-body-size: "2048M"
  proxy-buffer-size: "16k"
  worker-shutdown-timeout: "180"

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

node_labels:
  node-role.kubernetes.io/ingress: "true" # всем севрерам в группе kube-ingress ставить соответствующую метку
node_taints:
  - "node-role.kubernetes.io/ingress=:NoSchedule"

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

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

# ansible-playbook -u root -k -i inventory/dev/inventory.ini -b --diff cluster.yml

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

Установка Kubernetes

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

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

# kubectl get nodes

Информация о кластере

Вы увидите список всех нод и их роли. Я не знаю по какой причине, но при разворачивании кластера для этой статьи, у меня рабочие ноды не получили роли node. Исправить это можно командами.

# kubectl label node kub-node-1 node-role.kubernetes.io/node=
# kubectl label node kub-node-2 node-role.kubernetes.io/node=
# kubectl label node kub-ingress-1 node-role.kubernetes.io/node=

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

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

# kubectl label node kub-ingress-1 node-role.kubernetes.io/node-

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

# kubectl get nodes
# kubectl cluster-info

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

# kubectl describe node kub-master-1

Информация о ноде кластера kubernetes

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

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

# kubectl get pod -A

Все работающие поды

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

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

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

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

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

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

# echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
            Not Before: Sep 18 19:32:42 2019 GMT
            Not After : Sep 17 19:32:42 2020 GMT

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

# echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
            Not Before: Sep 18 18:35:36 2019 GMT
            Not After : Sep 17 18:35:36 2020 GMT

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

# echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
            Not Before: Sep 18 18:35:35 2019 GMT
            Not After : Sep 17 18:35:35 2020 GMT

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

# echo -n | openssl s_client -connect localhost:2379 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
            Not Before: Sep 18 19:28:50 2019 GMT
            Not After : Aug 25 19:28:50 2119 GMT

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

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

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

Онлайн курсы по Mikrotik

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую пройти курсы по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Помимо официальной программы, в курсах будут лабораторные работы, в которых вы на практике сможете проверить и закрепить полученные знания. Все подробности на сайте . Стоимость обучения весьма демократична, хорошая возможность получить новые знания в актуальной на сегодняшний день предметной области. Особенности курсов:
  • Знания, ориентированные на практику;
  • Реальные ситуации и задачи;
  • Лучшее из международных программ.

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

28 комментариев

  1. Аватар

    Во время установки /
    1.
    Thursday 12 December 2019 12:14:28 +0000 (0:00:00.146) 0:00:00.146 *****
    ok: [localhost] => {
    «changed»: false,
    «msg»: «All assertions passed»
    }
    [WARNING]: Could not match supplied host pattern, ignoring: bastion

    2. На этом подвисает
    TASK [bootstrap-os : Fetch /etc/os-release] **********************************************************************************************************************
    Thursday 12 December 2019 12:14:30 +0000 (0:00:00.790) 0:00:02.803 *****

  2. Аватар

    Спасибо за статью.
    Небольшой апдэйт: в 16 релизе немного подтюнили метки и файл kube-ingress.yml должен выглядеть следующим образом:

    node_labels:
    node.kubernetes.io/ingress: «true»
    node_taints:
    — «node.kubernetes.io/ingress=:NoSchedule»

  3. Аватар
    Алексей

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

    Как описать разные подсети, если предположим, что kub-master-1 находится в сети 172.30.172.0, а остальные хосты в 172.30.168.0?

    • Zerox

      Я не силен в регулярных выражениях. Плюс, не проверял на практике, как работает flannel в разных подсетях. Я бы попробовал так:
      172\\.30\\.\\d{1,3}\\.\\d{1,3}
      По идее, это должно подойти, если я правильно понял логику данного выражения. У меня самого даже для моего примера не получилось с первого раза правильно описать подсеть. Я просто не сразу понял это выражение — \\d{1,3}.

  4. Аватар
    Алексей

    Про сертификаты — nagios-ом мониторю, остаётся 20 дней — матюгальников на почту. Всё, не продевается. Думаю, такое умеют и другие системы мониторинга.

    • Zerox

      С мониторингом нет вопросов, настроить не сложно. А как сертификаты обновляете? Там же целая процедура, не оставляющая права на ошибку.

  5. Аватар

    Спасибо за статью, после прочтения остался вопрос: Nginx Ingress Controller привязывается к конкретной ноде kub-ingress-1. Чем это обусловленно? Ведь получается, если упадет нода kub-ingress-1 — кластер превратиться в тыкву или подразумевается, что гипервизор нод обеспечивает HA и мы не рассматриваем варианта падения ноды?

    • Zerox

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

    • Zerox

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

      • Аватар

        Для этого Nginx Ingress Controller деплоится как kind: DaemonSet, то есть Nginx Ingress будет задеплоин на всех воркерах (или на всех воркерах с нужным label, если указанно). Балансировку, если говорить про bare metal за nat, можно организовать на роутере если он может в l4 l7, metallb или поставить перед k8s HAproxy и др.

        • Zerox

          А какой в итоге ip адрес будет на ingress контроллере, чтобы на него слать запросы с внешнего балансера? Это будет dns имя со списком ip всех нод, где запущен ingress или какой-то плавающий ip, который кубер будет сам перекидывать между ингрессами? Как это технически реализуется, на какой технологии?

  6. Аватар
    Алексей

    Раз поднимается такая тема как Kubernetes, то может быть хотя бы параллельно сначала запустить цикл статьей про Docker? Так сказать, чтобы начать с основ.

    • Zerox

      Нет возможности писать об этом. К тому же в интернете полно материалов про docker, хотя лично я бесплатных хороших курсов не видел. Но можно на хабре поискать статьи. Там было много best practices, по которым можно научиться правильно с ним работать.

  7. Аватар

    Может я, конечно и лох, но под Centos 7 мне ни разу не удалось через кубеспрея установить кубер, если в его настройках была опция настройки докера. Сие чудо так раздалбывает system.d -скрипт, что запуск docker’a становится невозможным :) Вот если на все ее хосты заранее поставить докер запретить кубеспрею его настройку, то усё пройдет ОК

    • Zerox

      Вот мой пример, как установить на Centos 7. Я ни разу проблем не испытывал. Думаю, проблема была в том, что до какого-то обновления, вроде 7.4, если не ошибаюсь, у Centos 7 было старое ядро, в которое не портировали некоторые нововведения для нормальной работы докера. Вот в то время проблемы реально были, приходилось ставить новое 4.х ядро перед работой с докером. Но сейчас все это в прошлом и проблем нет.

  8. Аватар

    В качестве Ingress Controller можно же использовать HAProxy? Не будет ли гибче ситсема управления?

    • Zerox

      Можно, конечно. Удобство ingress именно в том, что он интегрирован в работу кластера, его легко и удобно настраивать. С HAProxy, как я понимаю, будет больше возни для получения того же результата.

  9. Аватар

    про ансибл , гит и тимсити особенно интересно ) Было бы здорово если бы у вас получилось написать статьи

  10. Аватар

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

  11. Аватар
    Алексей

    Владимир после того как ты вплотную занялся технологиями Devops не чувствуется необходимости на рабочей станции иметь или линукс или MacOS?

  12. Аватар

    Статье уже целый час! Когда продолжение?

Добавить комментарий

Ваш e-mail не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.