текст перекладу
Вступ
Red Hat Connectivity Link (RHCL) покращує з'єднання застосунків, управління політиками та управління API в багатохмарних та гібридних хмарних середовищах. Це дозволяє інженерам платформ та розробникам застосунків легко підключати, захищати та спостерігати за вашими API, застосунками та інфраструктурою.
У цьому блозі я проведу вас через процес розгортання Red Hat Connectivity Link (RHCL) на Azure Red Hat OpenShift (ARO) та налаштування шлюзу та політики DNS для тестового застосунку в кластерах.
Загальний потік трафіку
Необхідні вимоги
Перед тим як продовжити, переконайтесь, що виконані наступні умови:
1. Кластери ARO:
а. Розгорніть два кластери Azure Red Hat OpenShift (ARO) в різних регіонах. Для докладних інструкцій зверніться до документації Red Hat OpenShift на Azure.
б. Для цього блогу кластери розгорнуті в Центральній Індії та Сінгапурі.
Примітка: Будь-яке розгортання OpenShift може бути використано як альтернатива.
2. Інструменти CLI:
Переконайтесь, що на вашій системі встановлений клієнт oc або kubectl.
3. Службовий принципал Azure:
Налаштуйте службовий принципал Azure для управління DNS. Для інструкцій зверніться до документації Microsoft Azure.
4. Розгортання RHCL: Розгорніть RHCL за допомогою оператора. Наступні кроки обов'язкові:
а. Розгорніть Service Mesh 3.0 та створіть екземпляри Istio та IstioCNI.
б. Увімкніть функцію Gateway API.
oc get crd gateways.gateway.networking.k8s.io &> /dev/null || { oc kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.0.0" | oc apply -f -; }
в. Встановіть CertManager.
г. Встановіть RHCL.
д. Увімкніть консоль RHCL.
Налаштування шлюзу
Для балансування трафіку між двома або більше кластерами за допомогою DNS, необхідно налаштувати шлюз із загальним хостом. Це передбачає визначення HTTPS-слухача з підстановкою в ім'я хоста в домені. Переконайтесь, що ці ресурси застосовуються послідовно в усіх кластерах для забезпечення безперебійного розподілу трафіку.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gateway
namespace: gateway-ns
labels:
kuadrant.io/gateway: "true"
spec:
gatewayClassName: istio
listeners:
- allowedRoutes:
namespaces:
from: Same
hostname: '*.rhcl.shailendra14k.in'
name: api
port: 443
protocol: HTTPS
tls:
certificateRefs:
- group: ""
kind: Secret
name: api-cert-rhcl-tls
mode: Terminate
Розгорніть шлюз у обох кластерах ARO/OpenShift. У цьому налаштуванні шлюз розгорнуто в простору імен gateway-ns.
Перевірка
Після розгортання шлюзу він створить нову конфігурацію переднього IP на LoadBalancer. IP-адресу можна знайти в полі статусу шлюзу, як показано нижче:
spec:
gatewayClassName: istio
listeners:
- allowedRoutes:
namespaces:
from: All
hostname: '*.rhcl.shailendra14k.in'
name: api
port: 443
protocol: HTTPS
tls:
certificateRefs:
- group: ''
kind: Secret
name: api-cert-rhcl-tls
mode: Terminate
status:
addresses:
- type: IPAddress
value: 4.224.95.112
Конфігурації Azure Loadbalancer.
Налаштування політики DNS
1.
текст перекладу
Налаштування облікових даних провайдера Azure DNS:
cat <<-EOF > /path/to/azure.json
{
"tenantId": "$(az account show --query tenantId -o tsv)",
"subscriptionId": "$(az account show --query id -o tsv)",
"resourceGroup": "ExampleDNSResourceGroup",
"aadClientId": "$DNS_SP_APP_ID",
"aadClientSecret": "$DNS_SP_PASSWORD"
}
EOF
kubectl create secret generic my-test-azure-credentials \
--namespace=my-gateway-namespace \
--type=kuadrant.io/azure \
--from-file=azure.json= /path/to/azure.json
Перегляньте розділ документації 4.3. Налаштування облікових даних провайдера Azure DNS
- Політика DNS для кластера ARO в Центральній Індії
apiVersion: kuadrant.io/v1
kind: DNSPolicy
metadata:
name: gateway-dnspolicy
namespace: gateway-ns
spec:
targetRef:
name: gateway
group: gateway.networking.k8s.io
kind: Gateway
providerRefs:
- name: dns-provider-credentials-azure
loadBalancing:
weight: 120
geo: IN
defaultGeo: true
- Політика DNS для кластера ARO в Південно-Східній Азії (Сінгапур)
apiVersion: kuadrant.io/v1
kind: DNSPolicy
metadata:
name: gateway-dnspolicy
namespace: gateway-ns
spec:
targetRef:
name: gateway
group: gateway.networking.k8s.io
kind: Gateway
providerRefs:
- name: dns-provider-credentials-azure
loadBalancing:
weight: 120
geo: SG
defaultGeo: false
Примітка: Щоб дослідити різні значення для географічних конфігурацій DNS в Azure, ознайомтесь з наступною документацією: Azure Traffic Manager Geographic Regions.
Перевірка
Політика DNS створить кілька профілів Azure Traffic Manager на основі налаштувань конфігурації балансування навантаження. З цією конфігурацією буде створено три політики, як показано нижче, що дозволить здійснювати маршрутизацію на основі географічного положення з дефолтним маршрутом для Індії.
Примітка: Вищезазначена політика буде створена після налаштування HTTPRoute. Після перевірки увімкніть шлюз для іншого простору імен.
kubectl patch gateway ${gatewayName} -n ${gatewayNS} - type='json' -p='[{"op": "replace", "path": "/spec/listeners/0/allowedRoutes/namespaces/from", "value":"All"}]'
Розгортання застосунку
Розгорніть застосунок у обох кластерах ARO. Як приклад, я створив тестовий застосунок (real-demo), який відкриває деталі кластера через REST API. Як альтернативу, ви можете спробувати розгорнути приклад застосунку toystore за допомогою наступної конфігурації: toystore.yaml.
Налаштування HTTPRoute
Створіть HTTPRoute для обох кластерів.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: backend
labels:
deployment: backend-api
service: backend
spec:
parentRefs:
- name: gateway
namespace: gateway-ns
hostnames:
- api.rhcl.shailendra14k.in
rules:
- matches:
- method: GET
path:
type: PathPrefix
value: "/backend"
backendRefs:
- name: backend
Перевірка
При доступі до API бекенду з регіону Сінгапур, трафік маршрутизується до кластера ARO в Сінгапурі. Для запитів з інших регіонів трафік за замовчуванням направляється до кластера ARO в Центральній Індії, який виступає як резервний або кластер за замовчуванням. Це забезпечує ефективну маршрутизацію на основі географічного положення та оптимальне використання ресурсів.
текст перекладу
Доступ до API з віртуальних машин Сінгапуру
[admin123@demo ~]$ date
Wed Jan 22 10:11:42 PM +08 2025
[admin123@demo ~]$ nslookup api.rhcl.shailendra14k.in
Server: 168.63.129.16
Address: 168.63.129.16#53
Non-authoritative answer:
api.rhcl.shailendra14k.in canonical name = klb.rhcl.shailendra14k.in.
klb.rhcl.shailendra14k.in canonical name = shsingh-custom-ef67415eef581e47.trafficmanager.net.
shsingh-custom-ef67415eef581e47.trafficmanager.net canonical name = sg.klb.rhcl.shailendra14k.in.
sg.klb.rhcl.shailendra14k.in canonical name = shsingh-custom-c603e69356f46270.trafficmanager.net.
shsingh-custom-c603e69356f46270.trafficmanager.net canonical name = 2uxqy7-1gh6k8.klb.rhcl.shailendra14k.in.
Name: 2uxqy7-1gh6k8.klb.rhcl.shailendra14k.in
Address: 4.224.95.112
[admin123@demo ~]$ curl https://api.rhcl.shailendra14k.in/backend
"Backend called from Cluster:- ARO-Azure-Southeast-Asia-Singapore and POD hostName backend-api-d6d86466b-jsgvr"
- Доступ до API з інших регіонів.
➜ date
Wed 22 Jan 2025 21:42:01 IST
➜ nslookup api.rhcl.shailendra14k.in
Server: fe80::1%15
Address: fe80::1%15#53
Non-authoritative answer:
api.rhcl.shailendra14k.in canonical name = klb.rhcl.shailendra14k.in.
klb.rhcl.shailendra14k.in canonical name = shsingh-custom-ef67415eef581e47.trafficmanager.net.
shsingh-custom-ef67415eef581e47.trafficmanager.net canonical name = in.klb.rhcl.shailendra14k.in.
in.klb.rhcl.shailendra14k.in canonical name = shsingh-custom-06d81869613e2f89.trafficmanager.net.
shsingh-custom-06d81869613e2f89.trafficmanager.net canonical name = 18hghu-1gh6k8.klb.rhcl.shailendra14k.in.
Name: 18hghu-1gh6k8.klb.rhcl.shailendra14k.in
Address: 4.188.105.167
➜ curl https://api.rhcl.shailendra14k.in/backend
"Backend called from Cluster:- ARO-Azure-CentralIndia and POD hostName backend-api-56b9687bd4-8qb5j"
- Консоль RHCL
Консоль надає централізований інтерфейс для керування Red Hat Connectivity Links (RHCL) через кластери OpenShift. Вона спрощує налаштування політик, таких як DNSPolicy, AuthPolicy, RateLimitPolicy та TLSPolicy.
Висновок
У цьому блозі ми розглянули налаштування та конфігурацію Red Hat Connectivity Links (RHCL) на кластерах Azure Red Hat OpenShift (ARO), використовуючи DNSPolicy для управління трафіком на основі географічного положення. Це налаштування не лише покращує маршрутизацію трафіку, але й забезпечує високу доступність і ефективне використання ресурсів через кілька регіонів.
Це лише початок! У наступному блозі ми глибше розглянемо розширені функції RHCL, включаючи:
- AuthPolicy: Для керування автентифікацією та контролем доступу.
- RateLimitPolicy: Для налаштування обмежень трафіку та запобігання перевантаженню.
Слідкуйте за новими дописами, коли ми розкриватимемо ці розширені можливості.
Перекладено з: Deploying Red Hat Connectivity Link in Multi-Cluster Mode on Azure Red Hat OpenShift (ARO)