Visitors have accessed this post 14751 times.
Visitors have accessed this post 14751 times.
Автор — Андрей Трошин
Не для кого не секрет, что сегодня этот оркестратор у всех на слуху. Из каждого IT-утюга доносится «k8s, кластер, CI\CD» и всякие другие неприличные и малопонятные слова. Давайте разберемся и попробуем собрать кластер Kubernetes на VPS.
В качестве хост-системы будем использовать CentOS 7 на всех узлах нашего k8s кластера (если у вас другая хост-система — ищите информацию на официальном сайте Kubernetes). В нашем случае выбираем вариант установки с помощью Kubespray. Kubespray — это набор Ansible ролей для установки и конфигурации Kubernetes. В свою очередь, Ansible — это инструмент для автоматизации настройки и развертывания программного обеспечения.
В дальнейшем мы будем использовать кластер для публикации разных сервисов и поэтому установка будет на VPS. Но мануал по установке будет также успешно работать, если вы захотите поднять k8s у себя на виртуальных машинах.
Эта конфигурация — это учебный вариант. С таким количеством узлов кластера в продуктиве, конечно же, запускаться не стоит. С другой стороны, это уже не minikube, а разнесенный по узлам кластер, хоть и маленький 🙂
Итак, у нас в распоряжении 4 узла кластера и для дальнейших действий на всех узлах необходимо сделать следующее:
Поехали.
Отключаем SWAP.
swapoff -a
Отключаем Firewall.
firewall-cmd --state systemctl stop firewalld systemctl disable firewalld
Заходим на master ноду по ssh и генерируем ssh-ключ, копируем его на все хосты кластера (включая master хост, на котором был сгенерирован ключ). По очереди подставляем IP каждого узла кластера на место remote_host.
ssh-keygen ssh-copy-id root@remote_host
Продолжим подготавливать master. Для дальнейшей работы потребуется pip и собственно git.
curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py" python get-pip.py yum install git
С подготовительной частью мы закончили. Возвращаемся на master ноду и дальнейшие операции до конца установки кластера будем совершать с нее. Скачиваем репозиторий к себе на хост и переходим в директорию kubespray.
git clone https://github.com/kubernetes-sigs/kubespray.git cd kubespray
Далее устанавливаем python-библиотеку requests и другие зависимости из файла requirements.txt.
pip install --ignore-installed requests==2.23.0 pip install -r requirements.txt
В результате у нас получилось следующее:
Приступаем к конфигурации Kubespray. Для того чтобы Kubespray понимал, на какие узлы ему устанавливать k8s, необходимо создать директорию. В ней мы опишем конфигурацию будущего кластера. Копируем /inventory/sample/ в новую директорию и переименовываем, в моем случае — в root/, и в ней открываем файл inventory.ini.
[root@master-1 inventory]# ll total 12 drwxr-xr-x. 2 root root 4096 Nov 5 15:08 local drwxr-xr-x. 3 root root 4096 Nov 5 15:18 root drwxr-xr-x. 3 root root 4096 Nov 5 15:18 sample [root@master-1 inventory]# cd root/ [root@master-1 root]# ll total 8 drwxr-xr-x. 4 root root 4096 Nov 5 15:08 group_vars -rw-r--r--. 1 root root 994 Nov 5 15:08 inventory.ini [root@master-1 root]#
Типичный inventory.ini:
# ## Configure 'ip' variable to bind kubernetes services on a # ## different ip than the default iface # ## We should set etcd_member_name for etcd cluster. The node that is not a etcd member do not need to set the value, or can set the empty string value. [all] # node1 ansible_host=95.54.0.12 # ip=10.3.0.1 etcd_member_name=etcd1 # node2 ansible_host=95.54.0.13 # ip=10.3.0.2 etcd_member_name=etcd2 # node3 ansible_host=95.54.0.14 # ip=10.3.0.3 etcd_member_name=etcd3 # node4 ansible_host=95.54.0.15 # ip=10.3.0.4 etcd_member_name=etcd4 # node5 ansible_host=95.54.0.16 # ip=10.3.0.5 etcd_member_name=etcd5 # node6 ansible_host=95.54.0.17 # ip=10.3.0.6 etcd_member_name=etcd6 # ## configure a bastion host if your nodes are not directly reachable # bastion ansible_host=x.x.x.x ansible_user=some_user [kube-master] # node1 # node2 [etcd] # node1 # node2 # node3 [kube-node] # node2 # node3 # node4 # node5 # node6 [calico-rr] [k8s-cluster:children] kube-master kube-node calico-rr
Конфигурация не сложная, и на первый взгляд понятно, что в секции [all] идет присвоение IP-адресов ко всем нодам. В остальных секциях идет компановка кластера. Ниже приведен пример inventory.ini c моими IP-адресами (у вас они могут отличаться).
# ## Configure 'ip' variable to bind kubernetes services on a # ## different ip than the default iface # ## We should set etcd_member_name for etcd cluster. The node that is not a etcd member do not need to set the value, or can set the empty string value. [all] master-1.root.local.io ansible_host=192.168.0.5 ip=192.168.0.5 ingress-1.root.local.io ansible_host=192.168.0.4 ip=192.168.0.4 node-1.root.local.io ansible_host=192.168.0.6 ip=192.168.0.6 node-2.root.local.io ansible_host=192.168.0.3 ip=192.168.0.3 # ## configure a bastion host if your nodes are not directly reachable # bastion ansible_host=x.x.x.x ansible_user=some_user [kube-master] master-1.root.local.io [etcd] master-1.root.local.io [kube-node] node-1.root.local.io node-2.root.local.io ingress-1.root.local.io [kube-ingress-1] ingress-1.root.local.io [k8s-cluster:children] kube-node kube-master
Разберем, что следует из такой конфигурации:
Сохраняем изменения в inventory.ini и идем в директорию group_vars/. Создаем там файл kube-ingress.yml с содержимым:
node_labels: node-role.kubernetes.io/ingress: "" node_taints: - "node-role.kubernetes.io/ingress=:NoSchedule"
Это для корректной настройки Ingress контроллера. Далее редактируем файл k8s-cluster/addons.yml. Добавляем helm, сбор метрик для мониторинга и функционал Nginx ingress controller:
ingress_nginx_enabled: true
ingress_nginx_host_network: false
ingress_publish_status_address: ""
ingress_nginx_nodeselector:
kubernetes.io/os: "linux"
ingress_nginx_tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Equal"
value: ""
effect: "NoSchedule"
ingress_nginx_namespace: "ingress-nginx"
ingress_nginx_insecure_port: 80
ingress_nginx_secure_port: 443
ingress_nginx_configmap:
map-hash-bucket-size: "128"
ssl-protocols: "SSLv2"
ingress_nginx_configmap_tcp_services:
9000: "default/example-go:8080"
ingress_nginx_configmap_udp_services:
53: "kube-system/coredns:53"
ingress_nginx_extra_args:
- --default-ssl-certificate=default/foo-tls
Также редактируем k8s-cluster/k8s-cluster.yml. Меняем network plugin на flannel и имя нашего кластера на root.local:
Немножко подправим k8s-cluster/k8s-net-flannel.yml. Тут обычный regexp на сеть нашего провайдера VPS. У меня она 192.168.0.0/24. У вас может отличаться. Исправляем:
Готово! Конфигурация закончена. Мы в рамках пяти конфигурационных файлов, смогли описать все необходимое для сборки. Вспомним:
Теперь осталоcь запустить playbook Ansible, который соберет кластер, и дождаться его выполнения. Переходим в корень директории kubespray и выполняем в терминале команду:
ansible-playbook -u root -i inventory/root/inventory.ini cluster.yml -b --diff
Разберем параметры. Запускаем ansible-playbook от имени root с инвентарем inventary.ini. Дальше Ansible начнет свою работу по настройке кластера. Обычно это занимает от 10 до 20 минут. Если в это время у вас вдруг отвалиться соединение ssh или еще какая беда случится и прервется сборка, то ее можно запустить повторно и это не вызовет ошибок. В итоге, должно получиться как на скрине ниже.
Кластер собран и готов к работе. Проверяем состав нод командой kubectl get nodes.
[root@master-1 kubespray]# kubectl get nodes NAME STATUS ROLES AGE VERSION ingress-1.root.local.io Ready <none> 2d1h v1.19.3 master-1.root.local.io Ready master 2d1h v1.19.3 node-1.root.local.io Ready <none> 2d1h v1.19.3 node-2.root.local.io Ready <none> 2d1h v1.19.3
Видим, что кластер имеет одну мастер-ноду, две рабочие ноды и ингресс.
Но тут, если посмотреть в ROLE, можно заметить, что нашему Ingress-1 не назначена роль ingress. Исправляем kubectl label node ingress-1.root.local.io node-role.
kubernetes.io/ingress=ay]# kubectl label node ingress-1.root.local.io node-role. node/ingress-1.root.local.io labeled [root@master-1 kubespray]#
И повторно смотрим, чтобы назначилась нужная нам роль. Для расширенного просмотра информации по нодам можно использовать команду kubectl get nodes -owide.
[root@master-1 kubespray]# kubectl get nodes NAME STATUS ROLES AGE VERSION ingress-1.root.local.io Ready ingress 2d1h v1.19.3 master-1.root.local.io Ready master 2d1h v1.19.3 node-1.root.local.io Ready <none> 2d1h v1.19.3 node-2.root.local.io Ready <none> 2d1h v1.19.3 [root@master-1 kubespray]#
Поздравляю! У вас получилось собрать k8s кластер и теперь можно развернуть в нем простенькое приложение. Но это уже тема следующих статей.
Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.
*Анонсы мероприятий каждую неделю
Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.
Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.
Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.
Автор — Сергей Попов
Привет, друзья.
Вот уже полтора месяца я фигачу как полноценный devops engineer (одна штука) в команде разработки. Идет рефакторинг сервиса из монолита в микросервисы с деплоем в кубер. ЯП — GO + postgres + mongo + rabbit + мониторинг и логи.
Команда: 6 разработчиков + я + QA (1 шт). На мне, собственно, k8s на железе,...
Автор - Максим Рязанов
Всех приветствую! В этой статье я расскажу о Docker Swarm, его возможностях и основах взаимодействия с ним.
Пройдемся по следующим основным пунктам:
Построение кластера высокой доступности и управление кластером
Сервисы в Docker Swarm:
Режимы Replicated и Global
Файлы конфигурации и секреты
...
Появление DevOps в 2009 (хотя, по некоторым источникам, это все-таки было в 2008) в корне поменяло процесс взаимодействия между отделами разработки и эксплуатации. До этого момента это были два совершенно разные подразделения со своими целями, задачами и KPI. Как следствие, они не слишком вникали в деятельность друга и часто возникала абсолютно...
Cпасибо за статью. 2 обслуживающему персоналу — по какой причине код не влазит в форму, например выдача метки .
2 автор, этот вариант развернет ингресс на всех нодах , а нужен ли он нам везде, в том числе и на мастерах….. Я бы предложил поиграться с лейблом kubernetes.io/os: , точнее вместо него завести другой, соответствующий узко ингрессу.
2 сервис — функционал редактирования коммента скоро добавить? И спасибо автору за статью, ждем обещанного продолжения