По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
BGP - это сложный протокол маршрутизации, и бывают ситуации, когда что-то идет не так как надо. Кроме того, что он сложный, он также совершенно отличается от наших IGP протоколов (OSPF и EIGRP). В этой статье мы начнем с рассмотрения неполадок, возникающих в установлении соседства BGP, и как только это разберем, перейдем к проблемам с объявлением маршрутов, которые должны или не должны появляться!
Видео: Основы BGP за 7 минут
Урок 1
Начнем с нескольких простых сценариев. Два маршрутизатора BGP, которые подключены и настроены для EBGP. К сожалению, мы видим это, когда проверяем соседство BGP:
Когда два маршрутизатора EBGP, которые напрямую подключены, не образуют рабочее соседство BGP, может произойти ряд ошибок:
Layer 2 не позволяет нам добраться до другой стороны.
Проблема уровня 3: неправильный IP-адрес на одном из маршрутизаторов.
Список доступа, блокирующий TCP-порт 179 (BGP).
Неправильный IP-адрес настроен для соседнего маршрутизатора BGP
Мы можем использовать команду show ip bgp summary, чтобы проверить IP-адреса маршрутизаторов. Они, совпадают.
Мы выполним эхо запрос, с помощью команды ping. Видим, что, пакеты не могут добраться до другой стороны.
Проверяем интерфейсы и видим, что кто-то ввел команду отключения интерфейса.
R2(config)#interface fa0/0
R2(config-if)#no shutdown
"Поднимаем" интерфейс
Это прекрасно! Наше соседство BGP установлено. Это было легко!
Итог урока: убедитесь, что ваш интерфейс работает.
Урок 2
Следующая неполадка похожа на предыдущую, но немного отличается. Мы используем те же маршрутизаторы и номера AS, но на этот раз необходимо установить соседство BGP между интерфейсами обратной связи.
Посмотрим, как выглядит конфигурация BGP:
Вот конфигурация BGP. Как вы видите, мы используем loopback интерфейсы для установления соседства BGP-соседей.
Оба маршрутизатора показывают, что их сосед BGP бездействует. Есть ряд вещей, которые мы должны проверить здесь:
Доступен ли IP-адрес соседа BGP? Мы не используем прямые линии связи, поэтому у нас могут возникнуть проблемы с маршрутизацией.
TTL IP-пакетов, которые мы используем для внешнего BGP, равен 1. Это работает для сетей с прямым подключением, но, если они не подключены напрямую, нам нужно изменить эту настройку.
По умолчанию BGP будет получать обновления с IP-адреса, ближайшего к соседу BGP. В нашем примере это интерфейс FastEthernet. Это то, что мы должны изменить.
Начнем с маршрутизации. Оба маршрутизатора знают только о своих напрямую подключенных сетях. Чтобы достичь loopback интерфейсов друг друга, мы будем использовать статическую маршрутизацию.
R1(config)#ip route 2.2.2.2 255.255.255.255 192.168.12.2
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
Два статических маршрута должны выполнить эту работу.
Отправка ping на IP-адрес 2.2.2.2 и получение его из нашего собственного loopback интерфейса доказывает, что оба маршрутизатора знают, как связаться с loopback интерфейсом друг друга.
R1(config-router)#neighbor 2.2.2.2 ebgp-multihop 2
R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2
Команда ebgp-multihop изменяет TTL на 2.
Мы можем включить отладку, чтобы увидеть прогресс. Ясно видно, что R2 использует IP-адрес 192.168.12.2, а R1 отказывается от соединения.
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
Используйте команду update-source, чтобы изменить IP-адрес источника для обновлений BGP.
Соседство BGP работает!
Итог урока: маршрутизаторам BGP не требуется устанавливать соседство с использованием напрямую подключенных интерфейсов. Убедитесь, что маршрутизаторы BGP могут связаться друг с другом, что пакеты BGP получены из правильного интерфейса, и в случае EBGP не забудьте использовать команду multihop.
Урок 3
Продолжим рассмотрение некоторых проблем IBGP. Два маршрутизатора в одной AS и вот конфигурация:
Легко и просто. Маршрутизаторы используют напрямую подключенные IP-адреса для соседства BGP.
Жаль ... мы не становимся соседями. Что может быть не так? Мы используем напрямую подключенные интерфейсы, поэтому не так много проблем, если не считать проблемы L2 / L2.
Отправка пинга с одного маршрутизатора на другой доказывает, что L2 и L3 работают нормально. Как насчет L3? У нас могут быть проблемы с транспортным уровнем.
Я не могу подключиться к TCP-порту 179 с обоих маршрутизаторов. Это звоночек в сторону того, что что-то блокирует BGP?
Вот оно! Это Служба безопасности.…
Кто-то решил, что было бы неплохо "обезопасить" BGP и заблокировать его списком доступа.
R2(config)#interface fastEthernet 0/0
R2(config-if)#no ip access-group 100 in
Удалим список доступа.
Итог урока: не блокируйте TCP-порт BGP 179.
Урок 4
Следующая проблема IBGP. Это похоже на ситуацию с EBGP ранее...мы будем использовать loopback-интерфейсы для установления соседства BGP, вот конфигурации:
Ничего особенного, IBGP и мы используем loopback интерфейсы.
Не повезло здесь ... нет соседей. Давайте сначала проверим, могут ли маршрутизаторы получить доступ к loopback интерфейсам друг друга:
Быстрый взгляд на таблицу маршрутизации показывает нам, что это не так. Мы могли бы исправить это с помощью статического маршрута или IGP. Обычно мы используем IGP для IBGP для объявления loopback интерфейсов. Сейчас будем использовать OSPF:
R1(config)#router ospf 1
R1(config-router)#network 1.1.1.0 0.0.0.255 area 0
R1(config-router)#network 192.168.12.0 0.0.0.255 area 0
R2(config)#router ospf 1
R2(config-router)#network 192.168.12.0 0.0.0.255 area 0
R2(config-router)#network 2.2.2.0 0.0.0.255 area 0
Набор правильных команд OSPF должно сделать свою работу!
Отправка эхо-запроса, чтобы проверить, знают ли маршрутизаторы и как связаться с сетями друг друга, успешен.
Тем не менее, соседство BGP по-прежнему отсутствует
Отладка показывает, что в соединении отказано, а также показывает локальный IP-адрес, который используется для BGP. Кажется, кто-то забыл добавить команду update-source, так что давайте исправим это!
R1(config)#router bgp 1
R1(config-router)#neighbor 2.2.2.2 update-source loopback 0
R2(config)#router bgp 1
R2(config-router)#neighbor 1.1.1.1 update-source loopback 0
Точно так же, как EBGP, мы должны установить правильный источник для наших пакетов BGP.
Задача решена! Единственное отличие от EBGP в том, что нам не нужно менять TTL с помощью команды ebgp-multihop.
Итог урока: распространенная практика настройки IBGP между loopback интерфейсами. Убедитесь, что эти loopback доступны и обновления BGP получены из loopback интерфейса.
Теперь, рекомендуем почитать вторую часть статьи по траблшутингу протокола BGP.
Давайте рассмотрим следующую ситуацию: Санта приносит игрушки всем хорошим девочкам и мальчикам.
На 2019 год в мире проживало 7 713 468 100 человек, около 26,3% из которых моложе 15 лет. Это 2 028 642 110 детей (лиц в возрасте до 15 лет) в мире.
Есть такое мнение, что Санта посещает детей не всех религий, поэтому мы обобщим и включим в рассмотрение только христиан и нерелигиозных людей. В совокупности это примерно 44,72% населения. Если мы предположим, что дети исповедуют ту же религию, что и родители, то получится, что Санта-Клаус должен посетить 907 208 751,6 детей.
Какой процент из этих детей хорошие? Это узнать невозможно; однако мы можем поработать с несколькими предположениями. Во-первых, Санта-Клаус действует больше из соображений оптимизма, а не экономии, так что, он, вероятно, был бы готов к возможности того, что каждый ребенок будет хорошим в любой год. Таким образом, он был бы готов дать игрушку каждому ребенку. Предположим, что это был отличный год и все 907 208 751,6 детей получили игрушки.
Подарков много, и, как мы знаем, все они сделаны эльфами Санты в его мастерской на Северном полюсе. Учитывая, что в году 365 дней, и один из них – Рождество, то будем считать, что у Санты есть 364 дня, чтобы сделать и упаковать 907 208 752 (округлим) подарка. Получается 2 492 331,74 подарка в день.
Почти два с половиной миллиона подарков в день – большая нагрузка для любой мастерской. Давайте рассмотрим два подхода, которые Санта может использовать, чтобы упаковать все подарки: конкурентное исполнение (конкурентность) и параллельное исполнение (параллелизм).
Последовательный процесс
Предположим, что в мастерской Санты-Клауса работает ровно один очень трудолюбивый и очень уставший эльф. Один подарок изготавливается за четыре этапа:
Раскрой дерева
Сборка и склейка игрушки
Роспись игрушки
Подарочная упаковка
Когда эльф только один, то в любой момент времени он может выполнять лишь один этап для одного подарка. Если бы эльф производил по одному подарку от начала и до конца, то этот процесс был бы последовательным. Но это не самый эффективный способ для того, чтобы изготовить два с половиной миллиона подарков за день. Например, эльфу придется ждать и при этом ничего не делать, пока клей на игрушке не высохнет, и он сможет перейти к следующему этапу.
Конкурентность
Для того, чтобы быть более продуктивным, эльф может работать над всеми подарками одновременно.
Вместо того, чтобы делать по одному подарку за раз, эльф сначала раскраивает всю древесину для всех игрушек, одну за другой. Когда все вырезано, эльф собирает и склеивает игрушки одну за другой. При такой одновременной обработки клей на первой игрушке успевает высохнуть (не требуя особого внимания со стороны эльфа), пока склеиваются другие игрушки. То же самое касается росписи и упаковки.
Так как один эльф может выполнять только одну задачу за раз, то, если он будет производить подарки одновременно, он будет использовать день максимально эффективно.
Параллелизм
Хотелось бы надеяться, что в мастерской Санты все же больше, чем один эльф. Чем больше эльфов, тем больше игрушек можно сделать одновременно в течение дня. Такая одновременная работа означает, что подарки производятся параллельно. Параллельная работа нескольких эльфов означает, что одновременно выполняется больше работы.
Эльфы, которые работают параллельно, также могут использовать конкурентность. Один эльф по-прежнему может решать только одну задачу за раз, поэтому самым эффективным вариантом будет иметь несколько эльфов, которые будут производить подарки одновременно.
Конечно, если в мастерской Санты, скажем, два с половиной миллиона эльфов, то тогда каждый эльф должен будет сделать максимум один подарок за день. В таком случае последовательная работа не снижает эффективности. И осталось бы еще 7 668,26 эльфов, которые приносили бы кофе и обед.
Санта-Клаус и многопоточность
После того, как эльфы выполнили всю тяжелую работу, Санта-Клаус должен доставить подарки – все 907 208 752.
Санте не нужно навещать каждого ребенка лично; только елку в доме. Итак, сколько же елок ему нужно посетить? Опять же, обобщая, мы скажем, что среднее количество детей в семье во всем мире составляет 2,45 (будем основываться на прогнозируемых коэффициентов рождаемости на этот год). Получается, что Санта должен посетить 370 289 286,4 дома. Давайте округлим до 370 289 287.
Сколько на это есть времени у Санты? Легенды гласят об одной ночи, что означает один оборот Земли, а, значит, 24 часа. NORAD это подтверждает.
Это значит, что Санта должен посетить 370 289 287 домов за 24 часа (86 400 секунд). Следовательно, его скорость должна составлять 4 285,75 домов в секунду, и мы еще не упоминали о, которое нужно для того, чтобы положить подарки под елку и взять печенье.
Понятно, что Санты в нашем измерении не существует. Хотя бы потому, что он достаточно пухлый и при этом он пролезает в дымоход (с зажженным огнем, оставаясь невредимым) с мешком игрушек для всех детей семьи. И это мы еще не учли тот факт, что его сани везут огромное количество игрушек для каждого верующего ребенка во всем мире и что они летают.
Существует ли Санта вне наших законов физики? Как мог кто-то реальный путешествовать по миру, доставляя посылки менее чем за 24 часа со скоростью 4 285,75 домов в секунду, и при это у него еще оставалось время на молоко, печенье и поцелуй мамочки?
Одно можно сказать наверняка: Санта пользуется Интернетом. Никакая другая технология еще не позволяла посылкам перемещаться так далеко и так быстро. Как бы там ни было, попытка охватить более четырех тысяч домов в секунду – непростая задача, даже имея в арсенале лучшее гигабитное Интернет-соединение, которое может предоставить Северный полюс. Как Санта может повысить свою эффективность?
Очевидно, что у этой загадки есть только один логичный ответ: Санта-Клаус – это многопоточный процесс.
Один поток
Давайте посмотрим на это все со стороны. Представим, что поток – это одна конкретная задача или детализированная последовательность инструкций, которую может выполнить Санта. Один поток может выполнить только одну задачу – положить подарок под елку. Поток – это некий компонент процесса, в данном случае процесса доставки подарков Санта-Клаусом.
Если бы Санта-Клаус был бы однопоточным, то он как любой однопоточный процесс мог бы выполнять лишь одну задачу за раз. Поскольку он стар и у него не такая хорошая память, то у него, вероятно, есть набор инструкций по доставке подарков, а также график, которого стоит придерживаться. Эти две вещи направляют поток Санты, пока его процесс не завершится.
Однопоточный Санта-Клаус работает примерно по следующей схеме:
Посадить сани у дома Тимми.
Достать подарок Тимми из саней.
Войти в дом через дымоход.
Найти рождественскую елку.
Положить подарок Тимми под рождественскую елку.
Выйти из дома через дымоход.
Взлететь на санях.
И так по кругу… еще 370 289 286 раз.
Многопоточность
Многопоточный Санта-Клаус, напротив, является доктором Манхэттеном Северного полюса. В мире существует все еще один Санта-Клаус, но у него есть удивительная способность размножить свое сознание и одновременно выполнять несколько наборов инструкций. Эти дополнительные рабочие задачи, или рабочие потоки, создаются и контролируются основным процессом доставки подарков Санта-Клауса.
Каждый рабочий поток действует независимо, выполняя свои инструкции. Так как все они являются копией сознания Санты, то у них есть его память, и они знают все, что знает Санта, в том числе то, как устроена планета, по которой они доставляют подарки, и откуда эти подарки брать.
Благодаря этим знаниям каждый поток может выполнять свой набор инструкций параллельно с другими потоками. Такой многопоточный параллелизм делает единственного и неповторимого Санта-Клауса максимально продуктивным.
Если в среднем выполнение доставки подарка занимает час, то Санте нужно создать всего 4 286 рабочих потоков. Совершая по одной доставке в час таким образом, Санта завершит все 370 289 287 поездок к концу ночи.
Конечно, чисто теоретически, Санта может создать даже 370 289 287 рабочих потоков, каждый из которых займется одним домом, чтобы доставить подарки всем детям! Это сделало бы Санту максимально продуктивны, а также объяснило бы, как ему удается съесть все эти печеньки с молоком, не объевшись. ????
Эффективное и счастливое многопоточное Рождество
Благодаря современным компьютерам мы наконец-то понимаем, как Санта-Клаус справляется с, казалось бы, невыполнимой задачей доставки игрушек хорошим девочкам и мальчикам по всему миру. От моей семьи вашей семье, я надеюсь, вы проводите отличное Рождество. И не за будьте повесить носки на полку маршрутизатора.
Конечно, все это никак не объясняет, как же все-таки северным оленям удается летать.
Подаренный компанией Google сообществу Opensource, Kubernetes теперь стал инструментом контейнерного хранения по выбору. Он может управлять и координировать не только среду выполнения докеров, но и среду контейнерного хранения объектов и Rkt.
Типичный кластер Kubernetes обычно имеет главный узел и несколько рабочих узлов или Minions. Управление рабочими узлами осуществляется из главного узла, что обеспечивает управление кластером из центральной точки.
Важно также отметить, что можно развернуть кластер с одним узлом Kubernetes, который обычно рекомендуется использовать для легких непроизводственных рабочих нагрузок. Для этого можно взять Minikube - инструмент, который управляет кластером K ubernetes с одним узлом в виртуальной машине.
В этом руководстве мы рассмотрим многоузловую установку кластера Kubernetes в системе Linux CentOS 7. Это учебное пособие основано на командной строке и требует доступа к окну терминала.
Требования
Иметь несколько серверов под управлением Centos 7 (1 главный узел, 2 рабочих узла). Рекомендуется, чтобы главный узел содержал по крайней мере 2 ЦП, хотя это не является строгим требованием.
Подключение к Интернету на всех узлах. Мы будем извлекать пакеты Kubernetes и докеров из хранилища. Кроме того, необходимо убедиться, что диспетчер пакетов yum установлен по умолчанию и может получать пакеты удаленно.
Вам также потребуется доступ к учетной записи с правами sudo или root. В этом учебном пособии я буду использовать свою учетную запись root.
Наш 3-узловой кластер будет выглядеть примерно так:
Установка кластера Kubernetes на главном узле
Для работы Kubernetes потребуется механизм контейнеризации. Для этой установки мы будем использовать docker, так как он самый популярный.
На главном узле выполняются следующие шаги.
Шаг 1: Подготовить имя узла, брандмауэр и SELinux
На главном узле задайте имя хоста и, если у вас нет DNS-сервера, обновите файл /etc/hosts.
# hostnamectl set-hostname master-node
# cat <<EOF>> /etc/hosts
10.128.0.27 master-node
10.128.0.29 node-1 worker-node-1
10.128.0.30 node-2 worker-node-2
EOF
Можно выполнить проверку связи с рабочим узлом 1 и рабочим узлом 2, чтобы убедиться в правильности работы обновленного файла хоста с помощью команды ping.
# ping 10.128.0.29
# ping 10.128.0.30
Затем отключите SElinux и обновите правила брандмауэра.
# setenforce 0
# sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
# reboot
Установите следующие правила брандмауэра для портов. Убедитесь, что каждая команда firewall-cmd возвращает результат.
# firewall-cmd --permanent --add-port=6443/tcp
# firewall-cmd --permanent --add-port=2379-2380/tcp
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10251/tcp
# firewall-cmd --permanent --add-port=10252/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd –reload
# modprobe br_netfilter
# echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
Шаг 2: Настройка Kubernetes Repo
Нужно будет вручную добавить хранилище Kubernetes, так как оно не установлено по умолчанию в CentOS 7.
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
Шаг 3: Установить Kubeadm и Docker
После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты.
# yum install kubeadm docker -y
После успешного завершения установки включите и запустите обе службы.
# systemctl enable kubelet
# systemctl start kubelet
# systemctl enable docker
# systemctl start docker
Шаг 4: Установка Kubernetes Master и настройка пользователя по умолчанию
Теперь мы готовы инициализировать Kubernetes Master, но до этого нужно отключить swap, чтобы запустить команду kubeadm init.
# swapoff –a
Инициализация Kubernetes master - это полностью автоматизированный процесс, управляемый командой kubeadm init, которую необходимо выполнить.
# kubeadm init
Инициализация Kubernetes master
Возможно, потребуется скопировать последнюю строку и сохранить ее в другом месте, поскольку нужно будет запустить ее на рабочих узлах.
kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41
Совет: Иногда эта команда может жаловаться на переданные аргументы (args), поэтому отредактируйте ее, чтобы избежать ошибок. Таким образом, вы удалите символ , сопровождающий --token, и ваша последняя команда будет выглядеть следующим образом.
kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41
После успешной инициализации Kubernetes необходимо разрешить пользователю начать использование кластера. В нашем случае мы хотим запустить эту установку от имени пользователя root, поэтому мы продолжим выполнение этих команд с этого же имени. Вы можете перейти на пользователя с поддержкой sudo, который вы предпочитаете, и запустить ниже с помощью sudo.
Чтобы использовать root, выполните следующие действия:
# mkdir -p $HOME/.kube
# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config
Чтобы быть пользователем с поддержкой sudo, выполните следующие действия:
$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
Теперь проверьте, активирована ли команда kubectl.
# kubectl get nodes
На этом этапе также можно заметить, что главный узел имеет статус NotReady. Это связано с тем, что сеть модулей еще не развернута в кластере.
Pod Network - это сеть наложения для кластера, которая развернута поверх текущей сети узла. Она предназначена для обеспечения возможности подключения через модуль.
Шаг 5: Настройка сети модуля
Применение сетевого кластера является очень гибким процессом в зависимости от потребностей пользователя и наличия множества доступных вариантов. Так как мы хотим сохранить нашу установку как можно проще, мы будем использовать плагин Weavenet, который не требует никакой конфигурации или дополнительного кода, и он предоставляет один IP-адрес на модуль, что отлично для нас. Для просмотра дополнительных параметров проверьте здесь.
Эти команды будут важны для настройки сети модуля.
# export kubever=$(kubectl version | base64 | tr -d '
')
# kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"
Теперь, если вы проверите статус главного узла, он должен показать "Ready"
# kubectl get nodes
Далее мы добавим рабочие узлы в кластер.
Настройка рабочих узлов для присоединения к кластеру Kubernetes
Следующие шаги будут выполнены на рабочих узлах. Эти шаги должны выполняться на каждом рабочем узле при присоединении к кластеру Kubernetes.
Шаг 1: Подготовить имя узла, брандмауэр и SELinux
На рабочем узле-1 и рабочем узле-2 задайте имя, а если у вас нет DNS-сервера, то обновите основные и рабочие узлы в файле /etc/hosts.
# hostnamectl set-hostname 'node-1'
# cat <<EOF>> /etc/hosts
10.128.0.27 master-node
10.128.0.29 node-1 worker-node-1
10.128.0.30 node-2 worker-node-2
EOF
Можно выполнить ping master-node для проверки правильности обновленного файла хоста.
Затем отключите SElinux и обновите правила брандмауэра.
# setenforce 0
# sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
Установите следующие правила брандмауэра для портов. Убедитесь, что все команды firewall-cmd возвращаются успешно.
# firewall-cmd --permanent --add-port=6783/tcp
# firewall-cmd --permanent --add-port=10250/tcp
# firewall-cmd --permanent --add-port=10255/tcp
# firewall-cmd --permanent --add-port=30000-32767/tcp
# firewall-cmd --reload
# echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
Шаг 2: Настройка Kubernetes Repo
Вам потребуется добавить хранилище Kubernetes вручную, так как оно не будет предварительно установлено на CentOS 7.
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
Шаг 3: Установить Kubeadm и Docker
После того, как пакет repo уже готов, вы можете продолжить и установить kubeadm и docker пакеты.
# yum install kubeadm docker -y
Запустите и включите обе службы.
# systemctl enable docker
# systemctl start docker
# systemctl enable kubelet
# systemctl start kubelet
Шаг 4: Присоединение рабочего узла к кластеру Кубернетов
Теперь для присоединения к кластеру требуется маркер, созданный kubeadm init. Его можно скопировать и вставить в узлы 1 и 2, если он был скопирован в другом месте.
# kubeadm join 10.128.0.27:6443 --token nu06lu.xrsux0ss0ixtnms5 --discovery-token-ca-cert-hash sha256:f996ea3564e6a07fdea2997a1cf8caeddafd6d4360d606dbc82314688425cd41
Как показано в последней строке, вернитесь к главному узлу и проверьте, присоединились ли рабочие узлы 1 и 2 к кластеру с помощью следующей команды.
# kubectl get nodes
Если все шаги выполнены успешно, на главном узле должны быть показаны узлы 1 и 2 в состоянии готовности.
На этом этапе мы успешно завершили установку кластера Kubernetes на Centos 7 и успешно взяли два рабочих узла. Теперь можно начинать создавать модули и разворачивать службы.