По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Kubernetes - это система с открытым исходным кодом, созданная для оркестровки, масштабирования и развертывания контейнерных приложений. Если вы хоть раз работали с Kubernetes, то знаете, насколько он полезен для управления контейнерами.
Вы также знаете, что контейнеры не всегда работают должным образом. Если появляется сообщение об ошибке, вам нужен быстрый и простой способ решить проблему.
Из этого туториала Вы узнаете, как перезапустить поды в Kubernetes.
Под (Pod) – наименьшая запускаемая единица в ноде. Это группа контейнеров, которые должны работать вместе.
Перезапуск подов Kubernetes
Допустим, один из подов в вашем контейнере сообщает об ошибке. В зависимости от политики перезапуска Kubernetes может попытаться автоматически перезапустить под, чтобы он снова заработал. Однако это не всегда решает проблему.
Если Kubernetes не может решить проблему самостоятельно, и вы не можете найти источник ошибки, перезапуск пода вручную - это самый быстрый способ вернуть приложение в рабочее состояние. Быстрое решение - вручную перезапустить затронутые поды. Это может сэкономить ваше время, особенно если ваше приложение работает и вы не хотите выключать службу.
Вот три простых способа сделать это.
Метод 1: Rolling Restart
Начиная с обновления 1.15, Kubernetes позволяет выполнять непрерывный перезапуск развертывания. В качестве нового дополнения к Kubernetes это самый быстрый метод перезапуска.
kubectl rollout restart deployment [deployment_name]
Вышеупомянутая команда выполняет пошаговое завершение работы и перезапускает каждый контейнер в вашем развертывании. Ваше приложение по-прежнему будет доступно, поскольку большинство контейнеров все еще будут работать.
Метод 2: Использование переменных среды
Другой способ - установить или изменить переменную среды, чтобы поды перезагружались и синхронизировались с внесенными вами изменениями. Например, вы можете изменить дату развертывания контейнера:
kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)"
В приведенном выше примере набор команд env настраивает изменение переменных среды, развертывание [deployment_name] выбирает ваше развертывание, а DEPLOY_DATE="$(date) изменяет дату развертывания.
Метод 3. Масштабирование количества реплик
Наконец, вы можете использовать команду масштабирования, чтобы изменить количество реплик неисправного пода. Установка этого количества на ноль по существу отключает под:
kubectl scale deployment [deployment_name] --replicas=0
Чтобы перезапустить под, используйте ту же команду, чтобы установить количество реплик на любое значение больше нуля:
kubectl scale deployment [deployment_name] --replicas=1
Когда вы устанавливаете количество реплик равным нулю, Kubernetes уничтожает реплики, которые ему больше не нужны.
Как только вы установите число больше нуля, Kubernetes создаст новые реплики. Новые реплики будут иметь другие имена, чем старые. Вы можете использовать команду kubectl get pods, чтобы проверить статус модулей и увидеть новые имена.
Итог
Kubernetes - чрезвычайно полезная система, но, как и любая другая система, она не безошибочна.
Когда все же возникают проблемы, вы можете использовать три перечисленных выше метода, чтобы быстро и безопасно заставить ваше приложение работать, не закрывая службу для ваших клиентов.
В сегодняшней статье покажем пример настройки DMVPN – Dynamic Multipoint VPN, что является VPN решением компании Cisco. Данное решение используется, когда требуется высокая масштабируемость и легкость настройки при подключении филиалов к головному офису.
DMPVN одно из самых масштабируемых и эффективных решений VPN поддерживаемых компанией Cisco. В основном оно используется при топологии Hub-and-Spoke, где вы хотели бы видеть прямые VPN туннели Spoke-to-Spoke в дополнение к обычным Spoke-to-Hub туннелям. Это означает, что филиалы смогут общаться с друг другом напрямую, без необходимости прохождение трафика через HQ. Как уже упоминали, эта технология является проприетарной технологией Cisco.
Если вам необходимо подключить более десяти сайтов к головному офису, то DMPVN будет идеальным выбором. Кроме того, DMPVN поддерживает не только Hub-and-Spoke, но и Full-Mesh топологию, так как все сайты имеют между собой связность без необходимости настройки статических VPN туннелей между сайтами.
Некоторые характеристики DMVPN
Для начала перечислим важные характеристики данного способа организации Site-to-Site VPN для лучшего понимания:
Центральный маршрутизатор (HUB) - данный роутер работает как DMVPN сервер, и Spoke маршрутизаторы работают как DMVPN клиенты;
У данного маршрутизатора есть публичный статический IP-адрес на WAN интерфейсе;
У Spoke маршрутизаторов на WAN интерфейсах может как статический, так и динамический публичный IP-адрес;
У каждого филиала (Spoke) есть IPSEC туннель к головному офису (Hub);
Spoke-to-Spoke - туннели устанавливаются при возникновении необходимости, когда есть движение трафика между филиалами. Таким образом, трафик может не ходить через головной офис, а использовать прямые туннели между филиалами;
Все туннели используют Multipoint GRE c IPSEC;
NHRP (Next Hop Resolution Protocol) - данный протокол используется для установления соответствий между приватными IP туннельных интерфейсов с публичными WAN адресами
Описанные выше NHRP соответствия будут храниться на NHRP сервере, чем в нашем случае является HUB роутер. Каждый филиал устанавливает соединение с головным офисом и регистрирует свой публичный IP-адрес и его приватный IP-адрес тунеля;
Когда филиалу необходимо отправить пакеты в подсеть другого филиала, он запрашивает NHRP сервер для получения информации о внешнем публичном адресе целевого филиала;
Для лучшей масштабируемости советуем использовать один из протоколов динамический маршрутизации между всеми роутерами – например, EIGRP;
Еще раз кратко о технологиях, которые использует DMVPN:
Multipoint GRE;
IPSEC;
NHRP – Next Hop Resolution Protocol;
Статическая или динамическая маршрутизация;
Настройка маршрутизатора
Конкретно в нашем примере у нас будет HUB маршрутизатор и два филиала. И, как было описано ранее, HUB – это DMVPN cервер, а филиалы – DMPVN клиенты.
В нашем примере в качестве маршрутизатора используется CISCO1921/K9
Сначала настраиваем HUB маршрутизатор – ему необходимо присвоить статический IP – адрес на внешнем WAN-интерфейсе:
! Настраиваем интерфейсы
interface GigabitEthernet0/0
description to Internet-WAN
ip address 10.10.10.1 255.255.255.252
!
interface GigabitEthernet0/1
description to LAN
ip address 192.168.160.1 255.255.255.0
duplex auto
! Настраиваем туннельный интерфейс, который является улучшенным GRE (Multipoint GRE)
interface Tunnel1
description DMVPN Tunnel
ip address 172.16.1.1 255.255.255.0 // выбираем приватную подсеть для туннелей
no ip redirects
ip nhrp authentication nhrp1234 // аутентификация между маршрутизаторами
ip nhrp network-id 1 // сетевой идентификатор, который должен быть одинаковым на всех маршрутизаторах
load-interval 30
keepalive 5 10
tunnel source GigabitEthernet0/0 // назначаем источником туннеля WAN интерфейс
tunnel mode gre multipoint // определяем туннель как mGRE
tunnel protection ipsec profile protect-gre // шифруем трафик в туннеле с помощью IPSEC
ip mtu 1440 // уменьшаем MTU для того, чтобы разрешить оверхед на mGRE и IPSEC
ip nhrp map multicast dynamic // разрешаем форвардить мультикаст трафик между туннелями.
! Настраиваем IPSEC на главном роутере
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 // принимать соединения от любого источника при наличии динамических филиалов
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
mode tunnel
!
!
crypto ipsec profile protect-gre // профиль добавленный к mGRE туннелю для шифрования
set security-association lifetime seconds 86400
set transform-set TS
! Настраиваем статическую маршрутизацию на HUB маршрутизаторе
ip route 192.168.164.0 255.255.255.0 172.16.1.2 // удаленные подсети доступны через IP удаленного туннеля
ip route 192.168.161.0 255.255.255.0 172.16.1.3 // удаленные подсети доступны через IP удаленного туннеля
Затем настраиваем маршрутизаторы в филиалах (Spoke роутеры) - у одного маршрутизатора статический айпишник на WAN интерфейсе, и у другого динамический, получаемый по DHCP. Первый маршрутизатор в филиале, с динамическим IP:
interface GigabitEthernet0/0
description WAN to Internet
ip address dhcp
duplex auto
speed auto
interface GigabitEthernet0/1
description To LAN
ip address 192.168.164.1 255.255.255.0
duplex auto
speed auto
interface Tunnel1
ip address 172.16.1.2 255.255.255.0 // помещаем в ту же подсеть что и другие туннели
no ip redirects
ip nhrp map multicast dynamic // разрешаем форвардить мультикаст трафик между туннелями
tunnel source GigabitEthernet0/0 // “source”- WAN интерфейс
tunnel mode gre multipoint
tunnel protection ipsec profile protect-gre
ip nhrp authentication nhrp1234
ip nhrp map 172.16.1.1 10.10.10.1 // соответствие HUB адреса туннеля с HUB адресом WAN
ip nhrp network-id 1
ip nhrp nhs 172.16.1.1 // настройка NHRP
ip nhrp registration no-unique // если NHRP процесс завершился (поиск соответствия) для определенного IP, то больше данный процесс не запустится
ip nhrp map multicast 10.10.10.1 // Отправка milticast трафика только в Hub. Головной маршрутизатор будет получать весь мультикаст трафик (например, обновления протокола маршрутизации) и отправлять его всем Spoke маршрутизаторам
ip mtu 1440
load-interval 30
keepalive 5 10
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0 // Филиалы должны разрешать подклюения с любого адреса для формирования IPSEC VPN туннелей с другими филиалами
!
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
mode tunnel
!
crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
ip route 192.168.160.0 255.255.255.0 172.16.1.1 // Маршрут для HUB
ip route 192.168.161.0 255.255.255.0 172.16.1.3 // Маршрут для другого филиала Spoke site
Второй филиальный маршрутизатор, со статическим IP:
interface GigabitEthernet0/0
description TO Internet
ip address 10.10.10.9 255.255.255.252
duplex auto
speed auto
interface GigabitEthernet0/1
description To: LAN
ip address 192.168.161.1 255.255.255.0
duplex auto
speed auto
interface Tunnel1
ip address 172.16.1.3 255.255.255.0 // должен быть в той же подсети что и другие туннели
no ip redirects
ip nhrp map multicast dynamic // разрешаем форвард мульткастов между туннелями.
tunnel source GigabitEthernet0/0
tunnel mode gre multipoint
tunnel protection ipsec profile protect-gre
ip nhrp authentication nhrp1234
ip nhrp map 172.16.1.1 10.10.10.1 // мапируем адрес HUB тунеля к WAN адресу
ip nhrp network-id 1
ip nhrp nhs 172.16.1.1 // настраиваем NHRP клиент с указанием адреса сервера
ip nhrp registration no-unique
ip nhrp map multicast 10.10.10.1
ip mtu 1440
load-interval 30
keepalive 5 10
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key isakmp1234 address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac
mode tunnel
!
!crypto ipsec profile protect-gre
set security-association lifetime seconds 86400
set transform-set TS
ip route 192.168.160.0 255.255.255.0 172.16.1.1 // маршрут до головного маршрутизатор
ip route 192.168.164.0 255.255.255.0 172.16.1.2 // маршрут до другого филиала
Переходим к тестированию:
show dmvpn // проверяем статус DMVPN и NHRP
show crypto isakmp sa // проверяем IPSEC cвязность между маршрутизаторами
ping 192.168.164.1 // пингуем для проверки
ping 192.168.1.1
В нашем примере использовалась статическая маршрутизация, но при большом количестве филиалов необходимо использовать протоколы динамический маршрутизации для уменьшения ручного труда и риска ошибки.
Если вы планируете перейти на CentOS 8 с CentOS 7, возможно, вам придется пропустить это, потому что CentOS 8 уходит. Если вы уже используете его, вам следует подумать о переходе на CentOS Stream 8 с CentOS Linux 8. CentOS (сокращение от Community ENTerprise Operating System) - это клон системы Red Hat Enterprise Linux (RHEL). CentOS широко известна своей стабильностью и надежностью и является популярным выбором для многих провайдеров веб-хостинга. Кроме того, это шлюз для людей, которые хотят изучать RHEL бесплатно. Однако разработчики CentOS объявили, что они переключают свое внимание на CentOS Stream.
Согласно официальному объявлению, CentOS Linux 8, как перестройка RHEL 8, завершится в конце 2021 года. CentOS Stream продолжится после этой даты, выступая в качестве ответвления (разработки) Red Hat Enterprise Linux. Другими словами, CentOS Stream будет скользящей предварительной версией (то есть бета-версией). Таким образом, CentOS Stream не будет повторной сборкой выпуска RHEL. Это промежуточное звено, которое будет находиться между Fedora и RHEL. Проще говоря, это больше не Fedora - RHEL - CentOS, а Fedora - CentOS - RHEL. С января 2022 года RHEL будет базироваться на CentOS, а не наоборот. Вы по-прежнему можете использовать CentOS 8 и отправлять патчи до 31 декабря 2021 года. Но CentOS 8 будет завершена рано в это же время в следующем году, и CentOS 9 не будет. Пользователи CentOS 7 не должны паниковать. CentOS 7 продлится до конца своей жизни в 2024 году.
Миграция на CentOS Stream 8 с CentOS Linux 8
Прежде всего, на всякий случай сделайте резервную копию важных данных.
Обновите CentOS 8 до последней доступной версии с помощью команды:
$ sudo dnf update
После обновления системы перезагрузите ее. Проверьте текущую версию CentOS 8 с помощью команды:
$ cat /etc/redhat-release
CentOS Linux release 8.3.2011
Затем включите репозиторий CentOS Stream с помощью команды:
$ sudo dnf install centos-release-stream
Получите примерно такой ответ
Last metadata expiration check: 0:35:27 ago on Wednesday 09 December 2020 12:44:07 PM IST.
Dependencies resolved.
=========================================================================
Package Arch Version Repo Size
=========================================================================
Installing:
centos-release-stream x86_64 8.1-1.1911.0.7.el8 extras 11 k
Transaction Summary
=========================================================================
Install 1 Package
Total download size: 11 k
Installed size: 6.6 k
Is this ok [y/N]: y
Downloading Packages:
centos-release-stream-8.1-1.1911.0.7.el8 17 kB/s | 11 kB 00:00
-------------------------------------------------------------------------
Total 5.9 kB/s | 11 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : centos-release-stream-8.1-1.1911.0.7.el8.x86_ 1/1
Verifying : centos-release-stream-8.1-1.1911.0.7.el8.x86_ 1/1
Installed:
centos-release-stream-8.1-1.1911.0.7.el8.x86_64
Complete!
Наконец, выполните следующую команду, чтобы перенести CentOS Linux 8 на CentOS Stream 8:
$ sudo dnf distro-sync
Команда distro-sync выполнит необходимые обновления, откатит или оставит выбранные установленные пакеты, чтобы они соответствовали последней версии, доступной из любого включенного репозитория. Если пакет не указан, учитываются все установленные пакеты. Введите Y и нажмите ENTER, чтобы начать переход на CentOS Stream 8:
Пример вывода
CentOS-Stream - AppStream 521 kB/s | 6.3 MB 00:12
CentOS-Stream - Base 304 kB/s | 2.3 MB 00:07
CentOS-Stream - Extras 5.1 kB/s | 7.0 kB 00:01
Last metadata expiration check: 0:00:01 ago on Wednesday 09 December 2020 01:22:28 PM IST.
Dependencies resolved.
========================================================================================================================================
Package Architecture Version Repository Size
========================================================================================================================================
Installing:
centos-stream-release noarch 8.4-1.el8 Stream-BaseOS 21 k
replacing centos-linux-release.noarch 8.3-1.2011.el8
replacing centos-release-stream.x86_64 8.1-1.1911.0.7.el8
Upgrading:
NetworkManager x86_64 1:1.30.0-0.2.el8 Stream-BaseOS 2.5 M
NetworkManager-libnm x86_64 1:1.30.0-0.2.el8 Stream-BaseOS 1.8 M
NetworkManager-team x86_64 1:1.30.0-0.2.el8 Stream-BaseOS 142 k
NetworkManager-tui x86_64 1:1.30.0-0.2.el8 Stream-BaseOS 322 k
avahi-glib x86_64 0.7-20.el8 Stream-BaseOS 14 k
avahi-libs x86_64 0.7-20.el8 Stream-BaseOS 62 k
bind-export-libs x86_64 32:9.11.20-6.el8
.
.
.
.
baseos 57 k
python3-subscription-manager-rhsm x86_64 1.28.5-1.el8 Stream-BaseOS 362 k
subscription-manager x86_64 1.28.5-1.el8 Stream-BaseOS 1.1 M
subscription-manager-rhsm-certificates x86_64 1.28.5-1.el8 Stream-BaseOS 258 k
usermode x86_64 1.113-1.el8 baseos 202 k
Transaction Summary
========================================================================================================================================
Install 9 Packages
Upgrade 107 Packages
Total download size: 205 M
Is this ok [y/N]: y
Это займет некоторое время, в зависимости от скорости вашего интернета. После завершения миграции CentOS Stream 8 выполните следующую команду для проверки:
$ cat /etc/redhat-release
CentOS Stream release 8
Если вам нужен свежий ISO-образ CentOS Stream, вы можете получить его на официальной странице.