В Altenar мы часто используем RabbitMQ как точку входа для наших продуктов. В данном случае речь пойдет о системе, которая рассчитывает спортивные данные и предоставляет их как внутренним системам организации, так и внешним пользователям за её пределами. При проектировании системы для компонента RabbitMQ были определены следующие требования:
Endpoint защищён SSL-сертификатом.
RabbitMQ размещён в Kubernetes. Мы используем RabbitMQ cluster operator и RabbitMQ messaging topology operator.
-
Для этого проекта мы используем Google Cloud. Как и в случае с Let’s Encrypt, вы можете использовать управляемый SSL-сертификат Google Managed SSL Certificate для любого публичного HTTP Load Balancer в Google Cloud. Однако у такого подхода есть несколько ограничений, основные из которых:
Работает только с HTTP Load Balancer.
Работает только с публичными Load Balancer.
Согласно документации RabbitMQ, существует два распространённых подхода для подключения клиентов:
Настроить RabbitMQ для обработки TLS-подключений.
Использовать прокси или load balancer (например, HAproxy) для выполнения TLS-терминации клиентских подключений и использовать обычные TCP-подключения к узлам RabbitMQ.
Мы планировали использовать Google Managed Certificate для TCP/SSL Proxy Load Balancer в Google Cloud. Однако из-за вышеупомянутых ограничений управляемые сертификаты не поддерживаются для TCP Load Balancer. С другой стороны, Google позволяет использовать SSL-сертификаты для нескольких типов Load Balancer, что мы решили изучить. В результате итоговый проект выглядел бы следующим образом:
Мы хотели создать стандартный HTTP-сервис заглушку, который был бы доступен на порту 443 и использовался для управления SSL-сертификатом и его автоматического обновления.
При этом мы планировали иметь отдельный endpoint, который бы использовал тот же IP-адрес и тот же SSL-сертификат.
Рассмотрим каждую часть решения подробнее.
GKE Кластер
В качестве основной хостинг-платформы мы используем GKE (Google Kubernetes Engine). Мы используем Google Terraform module для настройки приватного GKE-кластера, конфигурируем Workload Identity и устанавливаем AutoNEG controller в кластер.
Мы не будем углубляться в детали работы Workload Identity с AutoNEG в этой статье, так как они используются в соответствии с официальной документацией.
После выполнения всех подготовительных шагов мы разворачиваем сервис-заглушку “Hello World” в кластере и подключаем его к Google Load Balancer с помощью AutoNEG. Ниже представлен YAML-конфигурация для этого:
apiVersion: apps/v1
kind: Deployment
metadata:
name: gcp-tls-certificate-issuer
labels:
app: gcp-tls-certificate-issuer
annotations:
deployment.kubernetes.io/revision: '1'
spec:
replicas: 2
selector:
matchLabels:
app: gcp-tls-certificate-issuer
template:
metadata:
labels:
app: gcp-tls-certificate-issuer
spec:
containers:
- name: ok
image: assemblyline/ok:latest
ports:
- containerPort: 8888
protocol: TCP
imagePullPolicy: Always
securityContext:
capabilities:
drop:
- ALL
runAsUser: 1000
runAsGroup: 3000
runAsNonRoot: true
readOnlyRootFilesystem: true
restartPolicy: Always
terminationGracePeriodSeconds: 30
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
revisionHistoryLimit: 10
progressDeadlineSeconds: 600
---
apiVersion: v1
kind: Service
metadata:
name: gcp-tls-certificate-issuer
labels:
app: gcp-tls-certificate-issuer
annotations:
cloud.google.com/neg: '{"exposed_ports": {"8888":{"name": "gcp-tls-certificate-issuer"}}}'
controller.autoneg.dev/neg: '{"backend_services":{"8888":[{"name":"envcode-rabbit-https-backend-service","max_connections_per_endpoint":10000}]}}'
spec:
ports:
- name: http
protocol: TCP
port: 8888
targetPort: 8888
selector:
app: gcp-tls-certificate-issuer
clusterIP: 10.10.12.130
clusterIPs:
- 10.10.12.130
type: ClusterIPОбратите внимание на аннотацию в конфигурации Service. Именно через неё AutoNEG добавляет этот сервис в Google Load Balancer как backend.
Google Load Balancer
Следующая часть настраивается вне GKE и создаётся отдельно. Google Load Balancer — это не единый объект, а набор различных объектов, объединённых вместе. Ниже представлен код Terraform с комментариями:
resource "google_compute_managed_ssl_certificate" "rabbitmq" {
project = var.project
name = "${var.environment_name}-google-managed-certificate-rabbitmq"
managed {
domains = ["rabitmq.example.com."] # Replace with your domain
}
}
# reserved IP address
resource "google_compute_global_address" "default" {
project = var.project
name = "tcp-proxy-xlb-ip"
}
output "rabbitmq-ip" {
value = google_compute_global_address.default.address
}
# forwarding rule for TCP Loadbalanser
resource "google_compute_global_forwarding_rule" "default" {
project = var.project
name = "${var.environment_name}-tcp-global-loadbalancer"
provider = google
ip_protocol = "TCP"
load_balancing_scheme = "EXTERNAL"
port_range = "5671"
target = google_compute_target_ssl_proxy.default.id
ip_address = google_compute_global_address.default.id
}
# https://cloud.google.com/load-balancing/docs/ssl
# When you use Google-managed SSL certificates with SSL Proxy Load Balancing, the frontend port for traffic must be 443 to enable the Google-managed SSL certificates to be provisioned and renewed.
# forwarding rule for HTTPS Loadbalanser
resource "google_compute_global_forwarding_rule" "https" {
project = var.project
name = "${var.environment_name}-https-global-loadbalancer"
provider = google
ip_protocol = "TCP"
load_balancing_scheme = "EXTERNAL"
port_range = "443"
target = google_compute_target_ssl_proxy.https.id
ip_address = google_compute_global_address.default.id
}
resource "google_compute_target_ssl_proxy" "default" {
project = var.project
name = "${var.environment_name}-global-loadbalancer-tcp-proxy"
backend_service = google_compute_backend_service.default.id
ssl_certificates = [google_compute_managed_ssl_certificate.rabbitmq.id]
}
resource "google_compute_target_ssl_proxy" "https" {
project = var.project
name = "${var.environment_name}-global-loadbalancer-https-proxy"
backend_service = google_compute_backend_service.https.id
ssl_certificates = [google_compute_managed_ssl_certificate.rabbitmq.id]
}
# backend service For RabbitMQ Autoneg
resource "google_compute_backend_service" "default" {
project = var.project
name = "${var.environment_name}-tcp-backend-service"
protocol = "TCP"
port_name = "tcp"
load_balancing_scheme = "EXTERNAL"
timeout_sec = 10
health_checks = [google_compute_health_check.default.id]
session_affinity = "CLIENT_IP"
# We don't want TF to remove whatever was configured by AutoNEG
lifecycle {
ignore_changes = [backend]
}
}
# backend service For HTTPS Autoneg
resource "google_compute_backend_service" "https" {
project = var.project
#that's what you use in the service annotations
name = "${var.environment_name}-https-backend-service"
protocol = "TCP"
port_name = "tcp"
load_balancing_scheme = "EXTERNAL"
timeout_sec = 10
health_checks = [google_compute_health_check.https.id]
# We don't want TF to remove whatever was configured by AutoNEG
lifecycle {
ignore_changes = [backend]
}
}
resource "google_compute_health_check" "default" {
project = var.project
name = "tcp-proxy-health-check"
description = "Backend service for AutoNEG"
timeout_sec = 1
check_interval_sec = 1
tcp_health_check {
port = "5672" #use container port
}
}
resource "google_compute_health_check" "https" {
project = var.project
name = "https-proxy-health-check"
description = "Backend service for AutoNEG"
timeout_sec = 1
check_interval_sec = 1
tcp_health_check {
port = "8888" #use container port
}
}Как вы можете видеть, мы создали один IP-адрес и один SSL-сертификат, а затем использовали их в двух правилах перенаправления (forwarding rules). Это позволило нам использовать управляемый SSL-сертификат для TCP Load Balancer.
Не забудьте настроить DNS и указать IP-адрес на правильное имя хоста, чтобы всё заработало.
Совет: В GKE есть deployment l7-default-backend. Возможно, было бы достаточно создать сервис с аннотациями AutoNEG и направить его на pod-ы этого deployment. Попробуйте это и сообщите в комментариях, если это работает.