По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Подаренный компанией 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 и успешно взяли два рабочих узла. Теперь можно начинать создавать модули и разворачивать службы.
Одним из преимуществ и популярности EIGRP является его быстрая конвергенция в случае сбоя связи. Однако одно, что может замедлить эту конвергенцию, - это конфигурация таймера. Именно этому посвящена эта статья, которая является третьей в серии статей о понимании EIGRP.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Часть 2. Про соседство и метрики EIGRP
Часть 2.2. Установка K-значений в EIGRP
Следующие статьи из цикла:
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Начнем наше обсуждение таймеров EIGRP с рассмотрения ситуации, когда два соседа EIGRP непосредственно связаны друг с другом. Если физическая связь между ними не работает, подключенный интерфейс каждого роутера отключается, и EIGRP может перейти на резервный путь (то есть возможный маршрут преемника). Такая ситуация показана на следующем рисунке:
Роутеры OFF1 и OFF2, показанные на приведенном выше рисунке, соединены друг с другом. Поэтому, если кабель между ними обрывается, каждый из интерфейсов роутера, соединяющихся с этим звеном, отключаются, и EIGRP понимает, что он просто потерял соседа и начинает перестраиваться. Однако нарушение связи между несколькими соседями EIGRP не всегда так очевидно. Например, рассмотрим вариант предыдущей топологии, как показано ниже:
Обратите внимание, что между роутерами OFF1 и OFF2 был подключен коммутатор (SW4) на рисунке выше. Если происходит сбой соединения между коммутатором SW4 и роутером OFF1, роутер OFF2 не сразу осознает это, потому что его порт Gig0/1 все еще находится в состоянии up/up. В результате роутер OFF2 может продолжать считать, что роутер OFF1 - это наилучший путь для доступа к сети, такой как 192.0.2.0 /24. К счастью, EIGRP использует таймеры, чтобы помочь EIGRP-спикер роутерам определить, когда они потеряли связь с соседом по определенному интерфейсу.
Таймеры, используемые EIGRP, - это таймеры Hello и Hold. Давайте задержимся на мгновение, чтобы изучить их работу, потому что таймер Hold не ведет себя интуитивно. Во-первых, рассмотрим таймер Hello. Как вы можете догадаться, это определяет, как часто интерфейс роутера отправляет приветственные сообщения своему соседу. Однако таймер Hold интерфейса - это не то, как долго этот интерфейс ожидает получения приветственного сообщения от своего соседа, прежде чем считать этого соседа недоступным. Таймер Hold - это значение, которое мы посылаем соседнему роутеру, сообщая этому соседнему роутеру, как долго нас ждать, прежде чем считать нас недоступными. Эта концепция проиллюстрирована на рисунке ниже, где роутер OFF2 настроен с таймером Hello 5 секунд и таймером Hold 15 секунд.
Два больших вывода из этого рисунка таковы:
Таймер Hello роутера OFF2 влияет на то, как часто он посылает приветствия, в то время как таймер Hold роутера OFF2 влияет на то, как долго роутер OFF1 будет ждать приветствий роутера OFF2.
Указанное время Hello и Hold является специфичным для интерфейса Gig 0/1 роутера OFF2. Другие интерфейсы могут быть сконфигурированы с различными таймерами.
Поскольку таймер Hold, который мы отправляем, на самом деле является инструкцией, сообщающей соседнему роутеру, как долго нас ждать, а не как долго мы ждем Hello-сообщения соседа, причем у каждого соседа может быть свой набор таймеров. Однако наличие совпадающих таймеров между соседями считается лучшей практикой для EIGRP (и является требованием для OSPF).
Чтобы проиллюстрировать конфигурацию и проверку таймеров EIGPR, допустим, что роутер OFF1 имел таймер Hello 1 секунду и таймер Hold 3 секунды на своем интерфейсе Gig 0/1 (подключение к OFF2). Затем мы захотели, чтобы роутер OFF2 имел таймер Hello 5 секунд и таймер Hold 15 секунд на своем интерфейсе Gig 0/1 (подключение к роутеру OFF1). Такая конфигурация укрепляет понятие того, что соседи EIGRP не требуют совпадающих таймеров (хотя лучше всего иметь совпадающие таймеры). В следующем примере показана эта конфигурация таймера для роутеров OFF1 и OFF2.
OFF1#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF1(config)#int gig 0/1
OFF1(config-if) #ip hello-interval eigrp 1 1
OFF1(config-if) #ip hold-time eigrp 1 3
OFF1(config-if) #end
OFF1#
OFF2#conf term
Enter configuration commands, one per line. End with CNTL/Z.
OFF2(config)#int gig 0/1
OFF2 (config-if) #ip hello-interval eigrp 1 5
OFF2 (config-if) #ip hold-time eigrp 1 15
OFF2(config-if) #end
OFF2#
Команда ip hello-interval eigrp asn h_intls вводится на каждом роутере для установки таймеров Hello. Параметр asn определяет настроенную автономную систему EIGRP равным 1, и таймер Hello для роутера OFF1 настроен равным 1 секунде, в то время как таймер Hello для роутера OFF2 настроен равным 5 секундам. Аналогично, команда ip hold-time eigrp asn ho_t вводится на каждом роутере для установки таймеров Hold. Опять же, обе команды задают автономную систему 1. Таймер Hold роутера OFF1 настроен на 3 секунды, в то время как таймер Hold роутера OFF2 настроен на 15 секунд. В обоих случаях таймер Hold EIGRP был настроен таким образом, чтобы быть в три раза больше таймера Hello. Хотя такой подход является обычной практикой, он не является обязательным требованием. Кроме того, вы должны быть осторожны, чтобы не установить таймер Hold на роутере со значением меньше, чем таймер Hello. Такая неверная конфигурация может привести к тому, что соседство будет постоянно "падать" и восстанавливаться. Интересно, что Cisco IOS действительно принимает такую неправильную конфигурацию, не сообщая ошибки или предупреждения.
EIGRP использует таймер Hello по умолчанию 5 секунд и таймер Hold по умолчанию 15 секунд на LAN интерфейсах. Однако в некоторых ситуациях на интерфейсах, настроенных для Frame Relay, таймеры по умолчанию будут больше.
Далее, посмотрим, как мы можем проверить настройки таймера EIGRP. Команда show ip eigrp neighbors, как показано в примере ниже, показывает оставшееся время удержания для каждого соседа EIGRP.
Обратите внимание в приведенном выше примере, что значение в столбце Hold равно 2 секундам для роутера OFF1 (то есть 10.1.1.1) и 13 секундам для роутера OFF3 (то есть 10.1.1.10). Эти цифры говорят нам о не настроенных таймерах Hold. Они говорят нам, сколько времени остается до того, как роутер OFF2 отключит этих соседей, в отсутствие приветственного сообщения от этих соседей. Роутер OFF2 перезапускает свой обратный отсчет времени Hold для роутера OFF3 до 15 секунд (таймер Hold роутера OFF3) каждый раз, когда он получает Hello сообщение от OFF3 (которое OFF3 отправляет каждые 5 секунд на основе своего таймера Hello). Поэтому, если вы повторно выполните команду show ip eigrp neighbors на роутере OFF2, вы, вероятно, увидите оставшееся время Hold для роутера OFF3 где - то в диапазоне 10-14 секунд. Однако, поскольку роутер OFF1 настроен с таймером Hold 3 секунды и таймером Hello 1 секунды, оставшееся время Hold, зафиксированно на роутере OFF2 для его соседства с роутером OFF1, обычно должно составлять 2 секунды.
Мы можем видеть настроенные значения таймера Hello и Hold для интерфейса роутера, выполнив команду show ip eigrp interfaces detail interface_id, как показано в примере ниже. Вы можете видеть в выходных данных, что интерфейс Gig 0/1 на роутере OFF2 имеет таймер Hello 5 секунд и таймер Hold 15 секунд.
Отлично, это закрепили. Теперь почитайте про пассивные интерфейсы в EIGRP.
Благодаря Linux, у нас есть очень много инструментов облегчающих администрирование и диагностику сети. В этом плане команда PING является одним из самых полезных инструментов для системных и сетевых администраторов.
Сама базовая возможность этой утилиты – определить доступен ли тот или иной хост. Тем не менее в этом материале мы приведем примеры расширенных возможностей этой команды в системе Linux.
Про Linux за 5 минут | Что это или как финский студент перевернул мир?