Развертывание OpenResty Nginx как обратного прокси в Kubernetes

OpenResty можно развернуть как фронтенд-обратный прокси в Kubernetes, создав пользовательское развертывание со специализированной конфигурацией nginx.conf, настроив Kubernetes-сервис для открытия доступа к прокси и сконфигурировав правильную VPC-сеть в EKS. Эта миграция с ECS на Kubernetes включает в себя контейнеризацию существующей настройки OpenResty, создание соответствующих Kubernetes-манифестов для развертывания и сервиса, а также обеспечение правильной сетевой конфигурации для маршрутизации трафика с балансировщика нагрузки через фронтенд-VPC к приложениям, работающим в кластере.

Содержание

• Понимание миграции архитектуры
• OpenResty против NGINX для обратного прокси в Kubernetes
• Настройка окружения Kubernetes
• Создание развертывания OpenResty
• Конфигурация Kubernetes-сервиса
• Конфигурация VPC и сети
• Вопросы безопасности
• Тестирование и валидация

Понимание миграции архитектуры

Ваша текущая архитектура на основе ECS с потоком Пользователь→Балансировщик нагрузки→Фронтенд-VPC→ECS-задачи→Приложения должна быть мигрирована в Kubernetes-эквивалент. В окружении Kubernetes поток должен быть следующим: Пользователь→Балансировщик нагрузки→Фронтенд-VPC→Kubernetes-сервис→Поды OpenResty→Приложения.

Как описано в исследовании, ключевое отличие заключается в том, что вместо ECS-задач вам понадобятся поды OpenResty, работающие в Kubernetes. OpenResty - это дистрибутив сервера, совместимый с nginx, который расширяет nginx мощными возможностями Lua, что делает его идеальным для сценариев динамического обратного проксирования.

Процесс миграции включает несколько ключевых компонентов:

• Контейнеризация существующей конфигурации OpenResty
• Создание Kubernetes-манифестов для развертывания и сервиса
• Настройка правильной VPC-сети для сохранения того же потока трафика
• Обеспечение правильной настройки групп безопасности и сетевых политик

При миграции следует учитывать, что Kubernetes предоставляет другие абстракции, чем ECS. Вместо определений задач вы будете использовать развертывания (deployments); вместо сервисов - Kubernetes-сервисы; и вместо балансировщиков нагрузки - как правило, контроллеры входа (ingress controllers) или сервисы балансировщика нагрузки.

OpenResty против NGINX для обратного прокси в Kubernetes

Хотя и OpenResty, и стандартный NGINX могут служить обратными прокси в Kubernetes, OpenResty предлагает несколько преимуществ для сложных сценариев проксирования:

Преимущества OpenResty:

• Скриптинг на Lua: Позволяет динамические изменения конфигурации без перезапуска подов
• Расширенное кэширование: Более сложные механизмы кэширования
• Возможности API-шлюза: Встроенная поддержка сложной логики маршрутизации
• Производительность: Оптимизирован для сценариев с высокой пропускной способностью

Как демонстрирует meyskens/k8s-openresty-ingress, OpenResty был протестирован в условиях высокого трафика и показывает отличные характеристики использования ресурсов.

Когда выбирать OpenResty:

• Вам нужны динамические обновления конфигурации
• Сложные правила маршрутизации требуют программной логики
• Требуется высокопроизводительное кэширование
• Вы мигрируете с существующих OpenResty ECS-задач

Соображения по стандартному NGINX:

• Более простое управление конфигурацией
• Более широкая поддержка сообщества
• Более обширные готовые образы
• Легкая интеграция с существующими контроллерами входа NGINX

Решение должно основываться на ваших конкретных требованиях. Если ваша текущая конфигурация OpenResty сильно relies on скриптинге Lua или динамических функциях, имеет смысл остаться с OpenResty в Kubernetes. Если ваши потребности в проксировании просты, стандартного NGINX может быть достаточно.

Настройка окружения Kubernetes

Перед развертыванием OpenResty убедитесь, что ваше окружение Kubernetes правильно сконфигурировано:

Предварительные требования

• EKS-кластер: Создайте или используйте существующий EKS-кластер в вашем фронтенд-VPC
• kubectl: Настроен для доступа к вашему EKS-кластеру
• IAM-роли: Убедитесь, что ваши рабочие узлы имеют соответствующие разрешения IAM
• Конфигурация VPC: Убедитесь, что ваш VPC имеет как минимум две подсети, как требуется в документации AWS

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

Согласно лучшим практикам EKS, при создании кластера необходимо указать как минимум две VPC-подсети. EKS размещает сетевой интерфейс (Elastic Network Interface) в каждой указанной подсети при создании кластера.

# Пример настройки VPC для EKS
eksctl create cluster \
  --name openresty-cluster \
  --region us-west-2 \
  --vpc-private-subnets subnet-12345678,subnet-87654321 \
  --without-nodegroups

Образ контейнера OpenResty

Используйте официальный образ OpenResty с Docker Hub:

image: openresty/openresty:alpine

Alternatively, вы можете создать пользовательский образ с вашей конкретной конфигурацией nginx:

FROM openresty/openresty:alpine
COPY nginx.conf /usr/local/openresty/nginx/conf/nginx.conf
COPY lua/ /usr/local/openresty/nginx/lua/

Создание развертывания OpenResty

Создайте Kubernetes-манифест развертывания для OpenResty на основе вашей существующей конфигурации ECS:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: openresty-proxy
  namespace: ingress
spec:
  replicas: 3
  selector:
    matchLabels:
      app: openresty-proxy
  template:
    metadata:
      labels:
        app: openresty-proxy
    spec:
      containers:
      - name: openresty
        image: openresty/openresty:alpine
        ports:
        - containerPort: 80
        - containerPort: 443
        volumeMounts:
        - name: nginx-config
          mountPath: /usr/local/openresty/nginx/conf/nginx.conf
          subPath: nginx.conf
        - name: ssl-certs
          mountPath: /etc/ssl/certs
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
      volumes:
      - name: nginx-config
        configMap:
          name: openresty-config
      - name: ssl-certs
        secret:
          secretName: ssl-certificates

Конфигурация ConfigMap

Создайте ConfigMap с вашей конфигурацией nginx:

apiVersion: v1
kind: ConfigMap
metadata:
  name: openresty-config
  namespace: ingress
data:
  nginx.conf: |
    worker_processes auto;
    error_log /var/log/nginx/error.log warn;
    events {
        worker_connections 1024;
        use epoll;
        multi_accept on;
    }
    http {
        include /etc/nginx/mime.types;
        default_type application/octet-stream;
        
        upstream backend {
            server backend-service:8080;
            keepalive 32;
        }
        
        server {
            listen 80;
            listen 443 ssl;
            server_name your-domain.com;
            
            ssl_certificate /etc/ssl/certs/your-domain.com.crt;
            ssl_certificate_key /etc/ssl/certs/your-domain.com.key;
            
            location / {
                proxy_pass http://backend;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_buffering on;
                proxy_buffer_size 4k;
                proxy_buffers 8 4k;
                proxy_busy_buffers_size 8k;
            }
        }
    }

Конфигурация Kubernetes-сервиса

Создайте Kubernetes-сервис для открытия доступа к вашему развертыванию OpenResty:

Сервис NodePort (для внутреннего доступа)

apiVersion: v1
kind: Service
metadata:
  name: openresty-service
  namespace: ingress
spec:
  selector:
    app: openresty-proxy
  ports:
  - port: 80
    targetPort: 80
    name: http
  - port: 443
    targetPort: 443
    name: https
  type: NodePort

Сервис LoadBalancer (для внешнего доступа)

apiVersion: v1
kind: Service
metadata:
  name: openresty-lb
  namespace: ingress
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
spec:
  selector:
    app: openresty-proxy
  ports:
  - port: 80
    targetPort: 80
    name: http
  - port: 443
    targetPort: 443
    name: https
  type: LoadBalancer

Сервис LoadBalancer создаст AWS Network Load Balancer, который направляет трафик к вашим подам OpenResty. Это соответствует вашей текущей архитектуре, где трафик течет от балансировщика нагрузки через фронтенд-VPC.

Конфигурация VPC и сети

Конфигурация VPC CNI

В EKS AWS VPC CNI - это плагин CNI по умолчанию, который развертывается автоматически при создании кластера. Согласно документации AWS, этот плагин предоставляет сетевое взаимодействие для подов с использованием AWS VPC.

Группы безопасности

Настройте группы безопасности для разрешения потока трафика:

1. Группа безопасности балансировщика нагрузки: Разрешить трафик из интернета на порты OpenResty (80, 443)
2. Группа безопасности OpenResty: Разрешить трафик от балансировщика нагрузки к подам OpenResty
3. Группа безопасности приложения: Разрешить трафик от подов OpenResty к бэкенд-сервисам

Сетевые политики

Включите сетевые политики для усиления безопасности:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: openresty-network-policy
  namespace: ingress
spec:
  podSelector:
    matchLabels:
      app: openresty-proxy
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress
    ports:
    - protocol: TCP
      port: 80
    - protocol: TCP
      port: 443
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: applications
    ports:
    - protocol: TCP
      port: 8080

Конфигурация Route53

Настройте DNS-записи для указания вашего домена на балансировщик нагрузки:

# Создание A-записи, указывающей на NLB DNS
aws route53 change-resource-record-sets \
  --hosted-zone-id YOUR_HOSTED_ZONE_ID \
  --change-batch '{
    "Comment": "Update OpenResty proxy DNS",
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "your-domain.com.",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{
          "Value": "your-nlb-dns-name.elb.us-west-2.amazonaws.com"
        }]
      }
    }]
  }'

Вопросы безопасности

Конфигурация SSL/TLS

• Используйте AWS Certificate Manager (ACM) для SSL-сертификатов
• Реализуйте правильное вращение сертификатов
• Настройте сильные наборы SSL-шифров
• Включите HTTP Strict Transport Security (HSTS)

Интеграция с IAM

• Используйте IAM-роли для сервисных аккаунтов (IRSA)
• Ограничьте разрешения только до необходимых AWS-ресурсов
• Реализуйте принцип наименьших привилегий

Безопасность подов

• Настройте ограничения и запросы ресурсов
• Используйте файловую систему только для чтения в корне
• Реализуйте политики безопасности подов или Pod Security Admission

Мониторинг и логирование

• Настройте метрики CloudWatch для OpenResty
• Настройте централизованное логирование
• Реализуйте проверки работоспособности и оповещения

Согласно лучшим практикам AWS EKS, убедитесь, что вы развернули поддерживаемую версию аддона VPC CNI и установили флаг ENABLE_NETWORK_POLICY в true для аддона vpc-cni для включения функциональности сетевых политик.

Тестирование и валидация

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

Настройте пробы работоспособности (liveness и readiness) в вашем развертывании:

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

Тестирование производительности

• Используйте инструменты вроде k6 или JMeter для тестирования пропускной способности
• Мониторьте задержку и частоту ошибок
• Тестируйте сценарии отказа
• Валидируйте балансировку нагрузки между подами

Валидация потока трафика

Проверьте полный поток трафика:

1. Запросы пользователей достигают домена
2. DNS разрешается до балансировщика нагрузки
3. Балансировщик нагрузки направляет трафик к подам OpenResty
4. OpenResty проксирует запросы к бэкенд-сервисам
5. Бэкенд-сервисы отвечают по тому же пути

Стратегия миграции

1. Разверните OpenResty вместе с существующей настройкой ECS
2. Настройте канареечную маршрутизацию для тестирования новой настройки
3. Постепенно перенаправьте трафик с ECS на Kubernetes
4. Мониторьте производительность и частоту ошибок
5. Завершите миграцию после валидации

Заключение

Развертывание OpenResty в качестве фронтенд-обратного прокси в Kubernetes включает несколько ключевых шагов: контейнеризация существующей конфигурации, создание правильных Kubernetes-манифестов, настройка VPC-сети и реализация лучших практик безопасности. Миграция с ECS на Kubernetes сохраняет тот же поток трафика (Пользователь→Балансировщик нагрузки→Фронтенд-VPC→Прокси→Приложения), используя при этом возможности оркестрации Kubernetes.

Ключевые выводы:

• Используйте официальные Docker-образы OpenResty или создавайте пользовательские образы с вашей конкретной конфигурацией
• Настройте правильные Kubernetes-сервисы (NodePort для внутреннего, LoadBalancer для внешнего доступа)
• Реализуйте VPC-сеть с соответствующими группами безопасности и сетевыми политиками
• Мониторьте и валидируйте полный поток трафика через новую архитектуру

Рекомендации:

1. Начните с среды разработки для тестирования миграции
2. Используйте канареечные развертывания для постепенного перенаправления трафика
3. Реализуйте комплексный мониторинг и логирование
4. Следуйте лучшим практикам AWS EKS для сетей и безопасности
5. Документируйте новую архитектуру для будущего обслуживания

Этот подход к миграции позволяет сохранить преимущества вашей текущей архитектуры на основе ECS, получая при этом преимущества оркестрации Kubernetes, масштабируемости и интеграции с экосистемой.

Источники

1. Dynamic reverse proxy using nginx in Kubernetes - Meain.io
2. Nginx as Reverse Proxy for Kubernetes Services - Reetesh Kumar
3. How to Set Up a Reverse Proxy in Kubernetes - Earthly.dev
4. GitHub - meyskens/k8s-openresty-ingress
5. AWS EKS Networking and VPC CNI - Kubedemy.io
6. VPC and Subnet Considerations - AWS EKS Best Practices
7. Deploying OpenResty Edge in Kubernetes - OpenResty Documentation
8. NGINX Kubernetes Ingress Controller - Solo.io
9. Network Security - AWS EKS Best Practices
10. Configure networking for Amazon EKS clusters - AWS Documentation