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

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

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .

Цели статьи

  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.kubernetes.io/ingress: "true" # всем серверам в группе kube-ingress ставить соответствующую метку
node_taints:
  - "node.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 контроллера. В последующих статьях я расскажу об основных сущностях kubernetes, как деплоить приложения в кластер с помощью Helm, как добавлять различные стореджи, как мониторить кластер и т.д. Да и в целом, хочу много о чем написать, но не знаю, как со временем будет.

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

Онлайн курс "DevOps практики и инструменты"

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по .

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

Автор Zerox

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

42 комментария

  1. Аватар
    Евгений

    Добрый день. Кластер установился и поднялся. Добавил сисьемного пользователя для доступа к дашбоард по инструкции. Но токен не проходит. Не сталкивались ?

    • Zerox

      К какому дашборду, не понял. Их много разных.

    • Аватар
      Владислав Б

      Привет, у тебя версия дашборда и кубера несовместимы.
      kubespray разворачивает старую версию морды, поэтому удаляй, устанавливай новую, создавай пользователя и вытаскивай его токен
      Выглядит примерно так (на мастере):

      kubectl delete deployments kubernetes-dashboard -n kube-system
      kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc2/aio/deploy/recommended.yaml

      kubectl create serviceaccount k8sadmin -n kube-system
      kubectl create clusterrolebinding k8sadmin —clusterrole=cluster-admin —serviceaccount=kube-system:k8sadmin
      kubectl get secret -n kube-system | grep k8sadmin | cut -d » » -f1 | xargs -n 1 | xargs kubectl get secret -o ‘jsonpath={.data.token}’ -n kube-system | base64 —decode

  2. Аватар
    Владимир

    Привет! статья очень полезная!
    у меня такая проблемка:
    [root@master1 ~]# ansible-playbook -u root -k -i /root/kubespray/inventory/dev/inventory -b —diff cluster.yml

    ERROR! the playbook: cluster.yml could not be found

    • Zerox

      Друг, если ты самостоятельно не можешь решить эту проблему, тебе нет смысла настраивать кластер. Без обид.
      Тут просто написано, что файл cluster.yml не найден. Найди его.

      • Аватар
        Владимир

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

        на мастере

        # kubeadm token create

        zfvcf0.domneur62fwy33mx

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

        # kubeadm token list

        TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS

        zfvcf0.domneur62fwy33mx 23h 2019-11-08T17:17:44+09:00 authentication,signing system:bootstrappers:kubeadm:default-node-token

        openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed ‘s/^.* //’

        5340ec383b25e0c52736970727c4a6f4c8b4ace09c023e1e9e9d26eb037fa9fe

        Обратите внимание, что апостроф в sed должен быть прямым.

        на новой ноде

        # kubeadm reset

        # kubeadm join 95.216.223.21:6443 —token zfvcf0.domneur62fwy33mx —discovery-token-ca-cert-hash sha256:5340ec383b25e0c52736970727c4a6f4c8b4ace09c023e1e9e9d26eb037fa9fe

        Не забываем подставлять свой IP

  3. Аватар

    подскажите пожалуйста — в чем может быть причина проблемы с подключением к кластеру:
    kub-master-2:~$ kubectl get nodes
    The connection to the server localhost:8080 was refused — did you specify the right host or port?
    порт 8080 не слушает ни одно из приложений ни на одном из мастеров :(

    повторная установка проходит без ошибок (ОС Ubuntu 18.04)

    PLAY RECAP ***********************************************************************************************************
    kub-ingress-1 : ok=359 changed=18 unreachable=0 failed=0
    kub-master-1 : ok=527 changed=35 unreachable=0 failed=0
    kub-master-2 : ok=486 changed=33 unreachable=0 failed=0
    kub-master-3 : ok=488 changed=33 unreachable=0 failed=0
    kub-node-1 : ok=389 changed=21 unreachable=0 failed=0
    kub-node-2 : ok=357 changed=18 unreachable=0 failed=0
    localhost : ok=1 changed=0 unreachable=0 failed=0

    Friday 31 January 2020 10:15:09 +0300 (0:00:00.488) 0:13:57.031 ********
    ===============================================================================
    container-engine/docker : Docker | reload docker ————————————————————- 31.32s
    kubernetes/master : Master | wait for kube-scheduler ——————————————————— 22.32s
    kubernetes/preinstall : Update package management cache (APT) ————————————————- 9.40s
    kubernetes-apps/ansible : Kubernetes Apps | Start Resources ————————————————— 6.99s
    download : download | Download files / images —————————————————————— 6.79s
    kubernetes-apps/network_plugin/flannel : Flannel | Wait for flannel subnet.env file presence —————— 5.53s
    download : download_container | Download image if required —————————————————- 5.35s
    kubernetes-apps/ansible : Kubernetes Apps | Lay Down CoreDNS Template —————————————— 5.14s
    kubernetes-apps/cluster_roles : PriorityClass | Create k8s-cluster-critical ———————————— 4.78s
    container-engine/docker : ensure docker packages are installed ———————————————— 4.52s
    download : download | Sync files / images from ansible host to nodes —————————————— 4.52s
    kubernetes/preinstall : Hosts | populate inventory into hosts file ——————————————— 4.25s
    kubernetes/master : kubeadm | write out kubeadm certs ——————————————————— 3.99s
    bootstrap-os : Fetch /etc/os-release ————————————————————————— 3.88s
    download : download | Sync files / images from ansible host to nodes —————————————— 3.61s
    kubernetes/master : Generate new kubeconfigs with correct apiserver ——————————————- 3.56s
    download : download | Sync files / images from ansible host to nodes —————————————— 3.43s
    download : download_container | Download image if required —————————————————- 3.35s
    download : download | Download files / images —————————————————————— 3.23s
    download : download | Sync files / images from ansible host to nodes —————————————— 3.21s

    • Zerox

      Так трудно сказать. Надо смотреть, что с докер контейнерами на хосте. Раз порт никто не слушает, значит они не запущены. Надо смотреть логи докера.

      • Аватар
        CONTAINER ID        IMAGE                                      COMMAND                  CREATED             STATUS              PORTS               NAMES
        ff3f40d33b40        680bc53e5985                               "/coredns -conf /etc…"   58 minutes ago      Up About an hour                        k8s_coredns_coredns-58687784f9-899xn_kube-system_18a802c1-cf2b-4fb1-905b-281f7a90cfd4_0
        a9396ec9ec37        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 58 minutes ago      Up About an hour                        k8s_POD_coredns-58687784f9-899xn_kube-system_18a802c1-cf2b-4fb1-905b-281f7a90cfd4_0
        25e4edeb6369        284f0d3c9420                               "/usr/local/bin/kube…"   59 minutes ago      Up About an hour                        k8s_kube-proxy_kube-proxy-zgln4_kube-system_472c44fb-c193-4c3a-bc9b-0a4d663c82f2_0
        7551ba6a69e8        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 59 minutes ago      Up About an hour                        k8s_POD_kube-proxy-zgln4_kube-system_472c44fb-c193-4c3a-bc9b-0a4d663c82f2_0
        96946faacfcd        6bed756ced73                               "kube-scheduler --au…"   About an hour ago   Up About an hour                        k8s_kube-scheduler_kube-scheduler-kub-master-2_kube-system_6f33d7866b72ca1b13c79edd42fa8dc6_0
        4207a2c65877        cd48205a40f0                               "kube-controller-man…"   About an hour ago   Up About an hour                        k8s_kube-controller-manager_kube-controller-manager-kub-master-2_kube-system_0441d7804a7366fd957f8b402008efe5_0
        652632ceeb97        ff281650a721                               "/opt/bin/flanneld -…"   About an hour ago   Up About an hour                        k8s_kube-flannel_kube-flannel-m9mgm_kube-system_42aed0bd-51e7-428e-b95d-2feaa9561b3a_3
        c64a9eb72bd6        221392217215                               "/install-cni.sh"        About an hour ago   Up About an hour                        k8s_install-cni_kube-flannel-m9mgm_kube-system_42aed0bd-51e7-428e-b95d-2feaa9561b3a_1
        7491bd3c275f        dfe4432cd2e2                               "/cluster-proportion…"   About an hour ago   Up About an hour                        k8s_autoscaler_dns-autoscaler-79599df498-zkmqj_kube-system_b71b6558-6179-4233-87f2-59b8e214c683_1
        7a74412a1e8a        a1efff7492c8                               "/node-cache -locali…"   About an hour ago   Up About an hour                        k8s_node-cache_nodelocaldns-xlxnq_kube-system_3ac08c31-fde4-4a87-84c0-e96494d7d869_2
        dca6335f1ccf        quay.io/coreos/etcd:v3.3.10                "/usr/local/bin/etcd"    About an hour ago   Up About an hour                        etcd2
        cf0e1c6b83d3        5732fe50f6f5                               "kube-apiserver --ad…"   About an hour ago   Up About an hour                        k8s_kube-apiserver_kube-apiserver-kub-master-2_kube-system_588f97b627d562291f19af19d9673f8a_1
        7ecd37e037fd        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_nodelocaldns-xlxnq_kube-system_3ac08c31-fde4-4a87-84c0-e96494d7d869_2
        c3057d933a63        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_dns-autoscaler-79599df498-zkmqj_kube-system_b71b6558-6179-4233-87f2-59b8e214c683_1
        16afb337e639        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_kube-scheduler-kub-master-2_kube-system_6f33d7866b72ca1b13c79edd42fa8dc6_2
        19b6ffb27d0f        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_kube-flannel-m9mgm_kube-system_42aed0bd-51e7-428e-b95d-2feaa9561b3a_1
        8c6d74d9faeb        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_kube-apiserver-kub-master-2_kube-system_588f97b627d562291f19af19d9673f8a_1
        cba5ca09a81d        gcr.io/google_containers/pause-amd64:3.1   "/pause"                 About an hour ago   Up About an hour                        k8s_POD_kube-controller-manager-kub-master-2_kube-system_0441d7804a7366fd957f8b402008efe5_1
    • Аватар

      сам отвечу на свой вопрос:

      ansible kub-master-* -m shell -a ‘mkdir -pv ~/.kube/ && sudo cp /etc/kubernetes/admin.conf ~/.kube/config’

      ansible kub-master-* -m shell -a ‘sudo chown $(whoami) ~/.kube/config’

      • Zerox

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

        • Аватар

          Порт слушается теперь только secure — 6443. Ещё возникли странные глюки с токеном для доступа к дашбоарду…Могу как-нибудь описать мои действия…

  4. Аватар

    Во время установки /
    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 *****

  5. Аватар

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

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

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

    «В данном случае 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}.

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

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

    • Zerox

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

  8. Аватар

    Спасибо за статью, после прочтения остался вопрос: 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, который кубер будет сам перекидывать между ингрессами? Как это технически реализуется, на какой технологии?

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

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

    • Zerox

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

  10. Аватар

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

    • Zerox

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

  11. Аватар

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

    • Zerox

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

  12. Аватар

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

  13. Аватар

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

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

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

  15. Аватар

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

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

Ваш адрес email не будет опубликован.

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