Раскрытие возможностей Ingress: подробное руководство по доступу к API службы Echo

В мире контейнерных приложений и микросервисов эффективное управление сетевым трафиком и маршрутизацией запросов имеет решающее значение. Kubernetes предлагает отличное решение этой проблемы благодаря своему ресурсу Ingress. В этой статье мы погрузимся в мир Ingress и рассмотрим различные методы доступа к API службы Echo, используя разговорный язык и практические примеры кода.

Метод 1: базовая конфигурация входящего трафика

Чтобы начать использовать ресурс Ingress, вам необходимо определить правила маршрутизации. Создайте входной файл YAML, указав правила хоста и пути для маршрутизации трафика в API службы Echo. Вот пример:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /echo
            pathType: Prefix
            backend:
              service:
                name: echo-service
                port:
                  number: 80

В этой конфигурации запросы к api.example.com/echoбудут перенаправляться на echo-service, работающий на порту 80.

Метод 2: прекращение SSL/TLS

Если вы хотите защитить соединение API с помощью SSL/TLS, вы можете включить завершение SSL/TLS во входном ресурсе. Вот пример:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  tls:
    - hosts:
        - api.example.com
      secretName: tls-secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /echo
            pathType: Prefix
            backend:
              service:
                name: echo-service
                port:
                  number: 80

Обязательно создайте секрет Kubernetes (tls-secretв этом примере), содержащий сертификат и ключ SSL/TLS.

Метод 3. Интеграция балансировщика нагрузки

Если вы используете свой кластер Kubernetes у облачного провайдера, такого как AWS или GCP, вы можете использовать встроенную интеграцию Load Balancer. Если добавить к вашему Ingress-ресурсу соответствующие аннотации, балансировщик нагрузки будет подготовлен автоматически. Вот пример:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /echo
            pathType: Prefix
            backend:
              service:
                name: echo-service
                port:
                  number: 80

В этом примере мы используем входной контроллер NGINX и предоставляем балансировщик сетевой нагрузки AWS (NLB) для повышения производительности и масштабируемости.

Метод 4. Входные контроллеры

Kubernetes позволяет использовать разные контроллеры Ingress в зависимости от ваших требований. Популярные варианты включают NGINX Ingress Controller, Traefik и HAProxy. Эти контроллеры предлагают дополнительные функции и настройки помимо базовой функциональности Ingress.

Чтобы установить NGINX Ingress Controller, вы можете использовать следующую команду:

kubectl create namespace ingress-nginx
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx -n ingress-nginx

Метод 5: маршрутизация на основе пути

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

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /echo
            pathType: Prefix
            backend:
              service:
                name: echo-service
                port:
                  number: 80
          - path: /status
            pathType: Prefix
            backend:
              service:
                name: status-service
                port:
                  number: 8080

В этом примере запросы к /echoбудут маршрутизироваться к echo-service, а запросы к /status— к status-service.