Как настроить отказоустойчивость для оператора статических маршрутов DigitalOcean

  • 277 просмотров
  • 5 минута чтения
Хади Бахадори
  • 20 июля 2024 г.
0 Акции
0
0
0
0
0
Акции
0
0
0
0

Введение

Основная цель статического оператора маршрутизации — обеспечить большую гибкость и контроль над сетевым трафиком в вашей среде Kubernetes. Он позволяет точно настроить конфигурацию маршрутизации в соответствии с требованиями приложения и оптимизировать производительность сети. Он развертывается как DaemonSet. Следовательно, он работает на каждом узле вашего кластера Kubernetes, управляемого DigitalOcean.

В этом руководстве вы научитесь управлять таблицей маршрутизации каждого рабочего узла в соответствии со спецификацией CRD и настраивать шлюз резервирования.

Основная цель этого руководства — показать, как управлять таблицей маршрутизации каждого рабочего узла в соответствии со спецификацией CRD и настроить шлюз для обеспечения отказоустойчивости.

Предпосылки
  • Управляемый DigitalOcean кластер Kubernetes, к которому у вас есть доступ.
  • На вашем локальном компьютере должен быть установлен Kubectl CLI (настроенный для подключения к кластеру Kubernetes, управляемому DigitalOcean).
  • Настройка и реализация NAT GW Droplets (2 или более новых версий) описаны здесь.
  • Создайте систему обнаружения сбоев в шлюзовом Droplet, адаптированную к потребностям пользователя и обеспечивающую четкое и точное обнаружение с минимальным количеством ложных срабатываний. Используйте сервисы мониторинга, такие как Prometheus или Nagios, настройте конечные точки проверки работоспособности в Droplet или инструменты оповещения, такие как Alertmanager. Для этой цели вы можете использовать стек мониторинга из нашего маркетплейса.

Ниже представлена схема архитектуры:

Развертывание оператора статических маршрутов Kubernetes

Разверните последнюю версию оператора статических маршрутов в вашем кластере Kubernetes, управляемом DigitalOcean, с помощью kubectl:

kubectl apply -f https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml
Убедитесь, что операторские модули запущены и работают:

Давайте проверим, запущены ли и работают ли операторские модули.

“ bash kubectl get staticroutes -o wide -n staticroutes

The output looks similar to the below:
```bash
[secondary_label Output]
NAME AGE DESTINATIONS GATEWAY
static-route-ifconfig.me 119s ["XX.XX.XX.XX"] XX.XX.XX.XX
static-route-ipinfo.io 111s ["XX.XX.XX.XX"] XX.XX.XX.XX

Теперь давайте проверим отчеты операторов, и никаких исключений обнаружено не должно:

kubectl logs -f ds/k8s-staticroute-operator -n static-routes

Вы должны увидеть следующий результат:

Output
Found 2 pods, using pod/k8s-staticroute-operator-498vv
[2023-05-15 14:12:32,282] kopf._core.reactor.r [DEBUG ] Starting Kopf 1.35.6.
[2023-05-15 14:12:32,282] kopf._core.engines.a [INFO ] Initial authentication has been initiated.
[2023-05-15 14:12:32,283] kopf.activities.auth [DEBUG ] Activity 'login_via_pykube' is invoked.
[2023-05-15 14:12:32,285] kopf.activities.auth [DEBUG ] Pykube is configured in cluster with service account.
[2023-05-15 14:12:32,286] kopf.activities.auth [INFO ] Activity 'login_via_pykube' succeeded.
[2023-05-15 14:12:32,286] kopf.activities.auth [DEBUG ] Activity 'login_via_client' is invoked.
[2023-05-15 14:12:32,287] kopf.activities.auth [DEBUG ] Client is configured in cluster with service account.
[2023-05-15 14:12:32,288] kopf.activities.auth [INFO ] Activity 'login_via_client' succeeded.
[2023-05-15 14:12:32,288] kopf._core.engines.a [INFO ] Initial authentication has finished.
[2023-05-15 14:12:32,328] kopf._cogs.clients.w [DEBUG ] Starting the watch-stream for customresourcedefinitions.v1.apiextensions.k8s.io cluster-wide.
[2023-05-15 14:12:32,330] kopf._cogs.clients.w [DEBUG ] Starting the watch-stream for staticroutes.v1.networking.digitalocean.com cluster-wide.

Для смягчения последствий сбоя шлюза рекомендуется иметь резервный шлюз, готовый к переключению в случае необходимости. Хотя оператор в настоящее время не поддерживает истинную высокую доступность (HA), переключение на резервный шлюз помогает минимизировать продолжительность перебоев в работе сервиса.

Допустим, у вас есть назначенный IP-адрес назначения, 34.160.111.145, который представляет собой активный или основной шлюз с IP-адресом 10.116.0.4, отвечающий за пересылку трафика. Эта информация хранится в файле primar.yaml.

apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: primary
spec:
destinations: 
- "34.160.111.145"
gateway: "10.116.0.4"

Кроме того, у вас будет резервный или дополнительный шлюз с IP-адресом 10.116.0.12, готовый обрабатывать трафик с того же целевого IP-адреса. Определение StaticRoute в файле secondary.yaml идентично определению основного шлюза, за исключением IP-адреса шлюза (и имени объекта). Это хранится в файле secondary.yaml.

apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: secondary
spec:
destinations: 
- "34.160.111.145"
gateway: "10.116.0.12"

Затем сам процесс отказа включает следующие этапы:

  • Обнаружено, что активный шлюз с IP-адресом 10.116.0.5 недоступен.
  • Удалите текущий активный статический маршрут.
  • Примените готовый статический маршрут.

Удалить активный статический маршрут

Теперь давайте удалим текущий активный статический маршрут.

kubectl delete -f primary.yaml

Подождите 30-60 секунд, чтобы дать каждому экземпляру оператора достаточно времени для обработки удаления объекта. То есть, в ответ удалите путь со всех узлов.

Применить резервный статический маршрут

Давайте включим дополнительный статический маршрут.

 kubectl apply -f secondary.yaml

Оператор должен выбрать новый резервный статический маршрут (StaticRoute) и вставить соответствующие записи в таблицу маршрутизации. После этого переключение на резервный маршрут завершено.

Настройка теста

Каждый экземпляр CRD создает статический маршрут к двум веб-сайтам, которые сообщают ваш публичный IP-адрес – ifconfig.me/ip и ipinfo.io/ip. Типичное определение статического маршрута выглядит следующим образом:

apiVersion: networking.digitalocean.com/v1
kind: StaticRoute
metadata:
name: static-route-ifconfig.me
spec:
destinations: 
- "34.160.111.145"
gateway: "10.116.0.5"

Для проверки настроек загрузите образец манифеста из указанного места:

Пример использования ifconfig.me и ipinfo.io.

curl -O https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/examples/static-route-ifconfig.me.yaml

curl -O https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/examples/static-route-ipinfo.io.yaml

После загрузки манифестов замените каждый файл манифеста на <>. Затем примените каждый манифест с помощью команды kubectl:

kubectl apply -f static-route-ifconfig.me.yaml

kubectl apply -f static-route-ipinfo.io.yaml

Наконец, проверьте, отвечает ли модуль curl-test на публичный IP-адрес вашего NAT-шлюза для каждого маршрута:

kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ip

При проверке отказоустойчивости следует использовать тот же тест. Во время переключения на основной шлюз результат должен показывать NAT-шлюз публичный IP-адрес основного шлюза, а во время переключения на резервный шлюз — публичный IP-адрес NAT-шлюза резервного шлюза.

Поиск неисправностей

Вам следует проверить объект StaticRoute: если возникает ошибка, сначала найдите ее в событии статического маршрута для каждого узла, к которому применяется правило.

kubectl get StaticRoute <static-route-name> -o yaml

Проверьте журналы: для более детального анализа вы можете проверить журналы оператора статических маршрутов на наличие ошибок.

kubectl logs -f ds/k8s-staticroute-operator -n static-routes

Стереть

Для удаления оператора и связанных с ним ресурсов выполните следующую команду kubectl (убедитесь, что используете ту же версию, что и при установке):

kubectl delete -f deploy https://raw.githubusercontent.com/digitalocean/k8s-staticroute-operator/main/releases/v1/k8s-staticroute-operator-v1.0.0.yaml

Результат, аналогичный следующему:

customresourcedefinition.apiextensions.k8s.io "staticroutes.networking.digitalocean.com" deleted
serviceaccount "k8s-staticroute-operator" deleted
clusterrole.rbac.authorization.k8s.io "k8s-staticroute-operator" deleted
clusterrolebinding.rbac.authorization.k8s.io "k8s-staticroute-operator" deleted
daemonset.apps "k8s-staticroute-operator" deleted

Теперь, если вы выполните ту же команду curl, в результате получите IP-адрес рабочего узла:

kubectl exec -it curl-test -- curl ifconfig.me/ip
kubectl exec -it curl-test -- curl ipinfo.io/ip

Теперь проверьте публичный IP-адрес рабочего узла:

kubectl get nodes -o wide

Результат

Внедрение механизмов резервирования, даже если истинная высокая доступность (HA) не полностью поддерживается, является рекомендуемым подходом для минимизации последствий сбоев шлюзов.

Организации могут значительно сократить продолжительность перебоев в предоставлении услуг, имея резервный шлюз, который при необходимости может переключиться на резервный.

Важно иметь резервный шлюз и обеспечить плавный переход в случае сбоя. Хотя реализация может варьироваться в зависимости от конкретных потребностей, приоритетное обеспечение готовности к сбоям поможет поддерживать надежное и бесперебойное предоставление услуг.

В этой статье:
Автор поста:
Следовать
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Предыдущая статья
Следующая статья
Вам также может понравиться