Краткие определения

• Ingress: объект Kubernetes, который управляет внешним доступом (HTTP/HTTPS) к сервисам внутри кластера.
• Ingress Controller: компонент, который реализует правила Ingress. Это фактически балансировщик нагрузки для Kubernetes.

Основная цель и варианты задач

Цель: быстро и корректно настроить Nginx Ingress Controller через Helm и проверить маршрутизацию по путям для нескольких приложений.

Варианты задачи, которые решаются этим гайдом:

• Настройка внешнего доступа к сервисам в кластере.
• Разделение трафика по пути на одно DNS-имя.
• Быстрое тестирование Ingress на примере nginx-приложений.

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

1. Аккаунт AWS.
2. Kops (пример: 1.18.2) установлен на вашей машине.
3. Helm v3 (например 3.5.3).
4. S3 bucket для состояния Kops.
5. Зарегистрованный домен и зона в Route53.
6. IAM-права для создания ресурсов (EC2, ELB/ALB, Route53, S3 и т.д.).

Важно: в статье предполагается, что вы знакомы с базовыми командами kubectl, kops и Helm.

Что мы сделаем — пошагово

1. Создадим Kubernetes-кластер с помощью Kops.
2. Установим Nginx Ingress Controller через Helm.
3. Создадим запись в Route53, указывающую на LoadBalancer.
4. Подготовим манифесты для трёх тестовых приложений.
5. Задеплоим приложения и Ingress с маршрутами по путям.

Создание Kubernetes-кластера с Kops

Экспортируйте временные ключи AWS в окружение:

export AWS_ACCESS_KEY_ID= #Export AWS Access Key

export AWS_SECRET_ACCESS_KEY= ##Export AWS Secret Key export

Задайте переменную состояния Kops, указывающую на ваш S3 bucket:

KOPS_STATE_STORE=s3://

Проверьте, что на момент инициализации в бакете нет кластеров:

kops get clusters

Пример команды создания кластера (замените значения на свои):

kops create cluster --name  --state s3:// --cloud aws --master-size t2.small --master-count 1 --master-zones us-east-1a --node-size t2.small --node-count 2 --zones us-east-1a,us-east-1b,us-east-1c

Вы увидите подсказки и рекомендованные команды для последующих шагов.

Выполните обновление конфигурации кластера (сначала dry-run, затем с –yes):

kops update cluster --name 

kops update cluster --name  --yes

Проверьте готовность кластера (ожидание до 10 минут):

kops validate cluster --wait 10m

Проверьте стандартные pod’ы по всем неймспейсам:

kubectl get pods -A

Установка Nginx Ingress Controller через Helm

Проверьте версию Helm:

helm version

Добавьте репозиторий и обновите кэши:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

helm repo update

Установите chart и включите публикацию сервиса, чтобы получить внешний LoadBalancer:

helm install nginx-ingress ingress-nginx/ingress-nginx --set controller.publishService.enabled=true

Проверьте созданные ресурсы:

kubectl get pods

kubectl get deployment

kubectl get service

Вы увидите сервис типа LoadBalancer, например nginx-ingress-ingress-nginx-controller. В AWS для него будет создан ELB/ALB.

Создание записи в Route53, указывающей на LoadBalancer

Откройте AWS Console в регионе, где создан кластер. Найдите LoadBalancer, созданный контроллером, и скопируйте DNS Name.

В Route53 создайте A-запись (или ALIAS), которая указывает на DNS Name LoadBalancer в Hosted Zone вашего домена.

После создания записи доменное имя (например kops.devopslee.com) начнёт направлять HTTP/HTTPS трафик в ваш Ingress Controller.

Создание манифестов для тестового приложения

Мы создадим три отдельных Deployment + Service для трёх приложений: main, green, blue. Затем настроим Ingress с маршрутизацией по путям.

Создайте файл 1-nginx-main-app.yaml:

Github Link: Click here to copy the file from my Github repo.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx-deploy-main
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx-main
  template:
    metadata:
      labels:
        run: nginx-main
    spec:
      containers:
      - image: nginx
        name: nginx


---
apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy-main
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    run: nginx-main

Создайте файл 2-nginx-green-app.yaml:

Github Link: Click here to copy the file from my Github repo.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx-deploy-green
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx-green
  template:
    metadata:
      labels:
        run: nginx-green
    spec:
      volumes:
      - name: webdata
        emptyDir: {}
      initContainers:
      - name: web-content
        image: busybox
        volumeMounts:
        - name: webdata
          mountPath: "/webdata"
        command: ["/bin/sh", "-c", 'echo "
I am GREEN
" > /webdata/index.html']
      containers:
      - image: nginx
        name: nginx
        volumeMounts:
        - name: webdata
          mountPath: "/usr/share/nginx/html"


---
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy-green
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    run: nginx-green          

Создайте файл 3-nginx-blue-app.yaml:

Github Link: Click here to copy the file from my Github repo.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx-deploy-blue
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx-blue
  template:
    metadata:
      labels:
        run: nginx-blue
    spec:
      volumes:
      - name: webdata
        emptyDir: {}
      initContainers:
      - name: web-content
        image: busybox
        volumeMounts:
        - name: webdata
          mountPath: "/webdata"
        command: ["/bin/sh", "-c", 'echo "
I am BLUE
" > /webdata/index.html']
      containers:
      - image: nginx
        name: nginx
        volumeMounts:
        - name: webdata
          mountPath: "/usr/share/nginx/html"


---
apiVersion: v1
kind: Service
metadata:
  name: nginx-deploy-blue
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    run: nginx-blue

Создайте файл 4-ingress.yaml с правилами маршрутизации по путям:

Github Link: Click here to copy the file from my Github repo.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: ingress-resource
spec:
  rules:
  - host: kops.devopslee.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-deploy-main
          servicePort: 80
      - path: /blue
        backend:
          serviceName: nginx-deploy-blue
          servicePort: 80
      - path: /green
        backend:
          serviceName: nginx-deploy-green
          servicePort: 80

Примечание: API версии для Ingress могут отличаться в зависимости от версии Kubernetes. В новых версиях используется networking.k8s.io/v1 — при необходимости обновите синтаксис.

Деплой тестовых приложений

Примените манифесты по очереди:

kubectl apply -f 1-nginx-main-app.yaml

kubectl apply -f 2-nginx-green-app.yaml

kubectl apply -f 3-nginx-blue-app.yaml

Проверьте статус:

kubectl get deployments

kubectl get pods

kubectl get service

Деплой Ingress и проверка логов

Перед созданием Ingress удобно открыть лог Nginx контроллера в режиме следования:

kubectl logs nginx-ingress-ingress-nginx-controller-5c97c6b4d5-btvpl -f

Затем примените Ingress:

kubectl apply -f 4-ingress.yaml

Как только ресурс создан, контроллер загрузит новую конфигурацию и начнёт обрабатывать запросы.

Примеры доступа:

• main: http://kops.devopslee.com/
• green: http://kops.devopslee.com/green
• blue: http://kops.devopslee.com/blue

Отладка и часто встречаемые проблемы

• Service не получает External IP: проверьте квоты AWS и наличие subnets/эндапойнтов, а также что тип сервиса — LoadBalancer.
• Ingress не обновляет конфигурацию: проверьте логи контроллера и аннотации в манифесте.
• Ошибка TLS: убедитесь, что в секции TLS Ingress указываете корректные секреты и certificate ARN при использовании ACM + ALB.
• Неправильная маршрутизация по пути: в новых API нужно указывать pathType: Prefix и корректный rewrite-target.

Короткие команды для диагностики:

kubectl describe ingress ingress-resource

kubectl describe svc nginx-ingress-ingress-nginx-controller

kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

Альтернативные подходы

• Использовать AWS Load Balancer Controller (ALB) вместо Nginx для tight интеграции с ALB/TargetGroups.
• Использовать Istio/Gateway API для более сложной маршрутизации и телеметрии.
• Разворачивать Nginx контроллер как DaemonSet при необходимости обработки на каждом узле.

Когда этот подход не подходит

• Если вам нужна L7-авторизация, фильтрация или сложные политики, лучше смотреть в сторону API Gateway или сервис-меш.
• Для статического контента с высокой производительностью может быть выгоднее CDN перед Ingress.

Ментальные модели и эвристики

• Ingress = правила маршрутизации (что делать).
• Ingress Controller = реализация этих правил (как делать).
• Service типа LoadBalancer = мост между Kubernetes и облачным LB.

Эвристика: сначала получите рабочий LoadBalancer и DNS, затем добавляйте сложные правила и TLS.

Критерии приёмки

• Helm chart установлен без ошибок и контроллер запущен.
• Сервис контроллера имеет внешний IP/DNS от облака.
• Запись в Route53 указывает на LB и резолвится.
• Запросы к kops.devopslee.com/ , /green и /blue возвращают соответствующие страницы.
• Логи контроллера показывают успешную загрузку конфигурации Ingress.

Ролевые чеклисты

Администратор облака:

• Наличие IAM прав.
• Создан S3 bucket.
• Проверены квоты и доступность AZ.

DevOps инженер:

• Kops и Helm установлены локально.
• Деплой кластера прошёл успешно.
• Установлен и проверен Ingress Controller.

Инженер приложений:

• Подготовлены манифесты Deployment и Service.
• Механизм health check приложения работает.

Тестовые сценарии и критерии приёмки

• Тест 1: GET / -> код 200, содержимое содержит “I am” для main.
• Тест 2: GET /green -> код 200, содержит GREEN.
• Тест 3: GET /blue -> код 200, содержит BLUE.
• Тест 4: Проверить, что при удалении одного pod’а другой продолжает обслуживать запросы.

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

• Если вы принимаете данные пользователей, включите HTTPS (TLS) на Ingress.
• Для автоматического выпуска TLS можно использовать cert-manager и ACME (Let’s Encrypt).
• Минимизируйте права IAM; используйте роли с наименьшими привилегиями.

Миграция и совместимость

• Обновление Kubernetes может потребовать миграции Ingress API с extensions/v1beta1 на networking.k8s.io/v1.
• При переходе проверьте pathType и структуру backend.

Мини-руководство по откату

1. Удалите ресурс Ingress: kubectl delete -f 4-ingress.yaml
2. Если нужно убрать контроллер: helm uninstall nginx-ingress
3. Для удаления кластера через Kops: kops delete cluster –name –yes

Краткое резюме

Мы создали кластер Kops, установили Nginx Ingress Controller через Helm, создали запись в Route53 и задеплоили 3 тестовых приложения с маршрутизацией по путям. Этот процесс даёт быстрый старт для управления HTTP/HTTPS трафиком в Kubernetes.

Важное: при работе в продакшн среде обязательно настраивайте TLS, мониторинг и ограничивайте IAM-права.

Полезные ссылки и ресурсы

• Официальная документация Nginx Ingress Controller: https://kubernetes.github.io/ingress-nginx
• Документация Kops: https://kops.sigs.k8s.io/
• Helm: https://helm.sh/

Короткий чеклист для запуска

• Создать S3 bucket и указать KOPS_STATE_STORE.
• kops create cluster и kops update cluster –yes.
• Дождаться kops validate cluster.
• helm repo add и helm install nginx-ingress.
• Создать запись в Route53 на LB.
• Применить 1-,2-,3- и 4- YAML файлы и проверить доступ.

Глоссарий (1 строка)

Ingress — объект Kubernetes для маршрутизации HTTP/HTTPS; Ingress Controller — компонент, реализующий эти правила и обеспечивающий входной трафик.

Авторская заметка: адаптируйте примеры манифестов под вашу версию Kubernetes и требования безопасности.