Поиск по сайту:

Как настроить Nginx Ingress с помощью Cert-Manager в Kubernetes

Введение

Kubernetes Ingresses позволяет вам гибко направлять трафик из-за пределов вашего кластера Kubernetes на службы внутри вашего кластера. Это достигается с помощью Ingress Resources, которые определяют правила для маршрутизации HTTP- и HTTPS-трафика к службам Kubernetes, и Ingress Controllers, которые реализуют правила, балансируя нагрузку трафика и направляя его в соответствующие серверные службы.

Популярные контроллеры Ingress включают Traefik. Ingress — это более эффективная и гибкая альтернатива настройке нескольких служб LoadBalancer, каждая из которых использует собственный выделенный Load Balancer.

В этом руководстве мы настроим поддерживаемое Kubernetes руководство по настройке входа Nginx в DigitalOcean Kubernetes с помощью Helm.

Предпосылки

Прежде чем приступить к работе с этим руководством, у вас должно быть в наличии следующее:

  • Кластер Kubernetes 1.15+ с другим методом.
  • Инструмент командной строки kubectl, установленный на вашем локальном компьютере и настроенный для подключения к вашему кластеру. Вы можете прочитать больше об установке kubectl Как подключиться к кластеру DigitalOcean Kubernetes, чтобы узнать, как подключиться к вашему кластеру с помощью kubectl.
  • Доменное имя и записи DNS A, которые вы можете указать на балансировщик нагрузки DigitalOcean, используемый Ingress. Если вы используете DigitalOcean для управления записями DNS вашего домена, ознакомьтесь с разделом «Как управлять записями DNS», чтобы узнать, как создавать записи A.
  • Утилита командной строки wget, установленная на вашем локальном компьютере. Вы можете установить wget с помощью диспетчера пакетов, встроенного в вашу операционную систему.

После настройки этих компонентов вы готовы начать работу с этим руководством.

Шаг 1 — Настройка фиктивных серверных служб

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

На локальном компьютере создайте и отредактируйте файл с именем echo1.yaml с помощью nano или вашего любимого редактора:

  1. nano echo1.yaml

Вставьте следующий манифест службы и развертывания:

apiVersion: v1
kind: Service
metadata:
  name: echo1
spec:
  ports:
  - port: 80
    targetPort: 5678
  selector:
    app: echo1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo1
spec:
  selector:
    matchLabels:
      app: echo1
  replicas: 2
  template:
    metadata:
      labels:
        app: echo1
    spec:
      containers:
      - name: echo1
        image: hashicorp/http-echo
        args:
        - "-text=echo1"
        ports:
        - containerPort: 5678

В этом файле мы определяем службу с именем echo1, которая направляет трафик в поды с помощью селектора меток app: echo1. Он принимает TCP-трафик через порт 80 и направляет его на порт 5678, порт http-echo по умолчанию.

Затем мы определяем развертывание, также называемое echo1, которое управляет модулями с помощью селектора меток app: echo1. Мы указываем, что развертывание должно иметь 2 реплики пода, и что поды должны запускать контейнер с именем echo1, на котором запущен образ hashicorp/http-echo. Мы передаем параметр text и устанавливаем для него значение echo1, чтобы веб-сервер http-echo возвращал echo1 . Наконец, мы открываем порт 5678 в контейнере Pod.

Как только вы будете удовлетворены фиктивным манифестом службы и развертывания, сохраните и закройте файл.

Затем создайте ресурсы Kubernetes с помощью kubectl apply с флагом -f, указав только что сохраненный файл в качестве параметра:

  1. kubectl apply -f echo1.yaml

Вы должны увидеть следующий вывод:

Output
service/echo1 created
deployment.apps/echo1 created

Убедитесь, что служба запущена правильно, подтвердив, что у нее есть ClusterIP, внутренний IP-адрес, на котором предоставляется служба:

  1. kubectl get svc echo1

Вы должны увидеть следующий вывод:

Output
NAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
echo1     ClusterIP   10.245.222.129   <none>        80/TCP    60s

Это означает, что служба echo1 теперь доступна внутри по адресу 10.245.222.129 через порт 80. Он будет перенаправлять трафик на containerPort 5678 в выбранных модулях.

Теперь, когда служба echo1 запущена, повторите этот процесс для службы echo2.

Создайте и откройте файл с именем echo2.yaml:

apiVersion: v1
kind: Service
metadata:
  name: echo2
spec:
  ports:
  - port: 80
    targetPort: 5678
  selector:
    app: echo2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo2
spec:
  selector:
    matchLabels:
      app: echo2
  replicas: 1
  template:
    metadata:
      labels:
        app: echo2
    spec:
      containers:
      - name: echo2
        image: hashicorp/http-echo
        args:
        - "-text=echo2"
        ports:
        - containerPort: 5678

Здесь мы по существу используем тот же манифест службы и развертывания, что и выше, но назовем и переименуем службу и развертывание echo2. Кроме того, для разнообразия мы создаем только 1 реплику пода. Мы гарантируем, что для параметра text установлено значение echo2, чтобы веб-сервер возвращал текст echo2.

Сохраните и закройте файл и создайте ресурсы Kubernetes с помощью kubectl:

  1. kubectl apply -f echo2.yaml

Вы должны увидеть следующий вывод:

Output
service/echo2 created
deployment.apps/echo2 created

Еще раз убедитесь, что служба запущена и работает:

  1. kubectl get svc

Вы должны увидеть службы echo1 и echo2 с назначенными ClusterIP:

Output
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
echo1        ClusterIP   10.245.222.129   <none>        80/TCP    6m6s
echo2        ClusterIP   10.245.128.224   <none>        80/TCP    6m3s
kubernetes   ClusterIP   10.245.0.1       <none>        443/TCP   4d21h

Теперь, когда наши фиктивные эхо-веб-сервисы запущены и работают, мы можем перейти к развертыванию Nginx Ingress Controller.

Шаг 2 — Настройка контроллера входа Kubernetes Nginx

На этом этапе мы развернем v1.1.1 Руководства по установке, поддерживаемого Kubernetes.

Nginx Ingress Controller состоит из модуля, который запускает веб-сервер Nginx и отслеживает уровень управления Kubernetes на наличие новых и обновленных объектов Ingress Resource. Ingress Resource — это, по сути, список правил маршрутизации трафика для серверных служб. Например, правило Ingress может указать, что HTTP-трафик, поступающий по пути /web1, должен быть направлен на внутренний веб-сервер web1. Используя Ingress Resources, вы также можете выполнять маршрутизацию на основе хоста: например, перенаправлять запросы, которые попадают на web1.your_domain.com, в серверную службу Kubernetes web1.

В этом случае, поскольку мы развертываем Ingress Controller в кластере DigitalOcean Kubernetes, контроллер создаст службу LoadBalancer, которая предоставляет балансировщик нагрузки DigitalOcean, на который будет направляться весь внешний трафик. Этот балансировщик нагрузки будет направлять внешний трафик на модуль Ingress Controller с Nginx, который затем перенаправляет трафик на соответствующие серверные службы.

Мы начнем с создания ресурсов Kubernetes Nginx Ingress Controller. Они состоят из ConfigMap, содержащих конфигурацию контроллера, ролей управления доступом на основе ролей (RBAC) для предоставления контроллеру доступа к API Kubernetes и фактического развертывания контроллера входящего трафика, в котором используется v1.1.1 образа Nginx Ingress Controller. Чтобы увидеть полный список этих необходимых ресурсов, обратитесь к манифесту из репозитория GitHub Kubernetes Nginx Ingress Controller.

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

Чтобы создать ресурсы, используйте kubectl apply и флаг -f, чтобы указать файл манифеста, размещенный на GitHub:

  1. kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/do/deploy.yaml

Здесь мы используем apply, чтобы в будущем мы могли постепенно применять изменения к объектам Ingress Controller, а не полностью перезаписывать их. Чтобы узнать больше о apply, обратитесь к разделу «Управление ресурсами» в официальной документации Kubernetes.

Вы должны увидеть следующий вывод:

Output
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created

Эти выходные данные также служат удобной сводкой всех объектов Ingress Controller, созданных из манифеста deploy.yaml.

Убедитесь, что модули Ingress Controller запущены:

  1. kubectl get pods -n ingress-nginx \

  2.   -l app.kubernetes.io/name=ingress-nginx --watch



Output
NAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-l2jhk       0/1     Completed   0          13m
ingress-nginx-admission-patch-hsrzf        0/1     Completed   0          13m
ingress-nginx-controller-c96557986-m47rq   1/1     Running     0          13m

Нажмите CTRL+C, чтобы вернуться к подсказке.

Теперь подтвердите, что балансировщик нагрузки DigitalOcean был успешно создан, получив сведения о сервисе с помощью kubectl:

  1. kubectl get svc --namespace=ingress-nginx

Через несколько минут вы должны увидеть внешний IP-адрес, соответствующий IP-адресу балансировщика нагрузки DigitalOcean:

Output
NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.245.201.120   203.0.113.0   80:31818/TCP,443:31146/TCP   14m
ingress-nginx-controller-admission   ClusterIP      10.245.239.119   <none>            443/TCP                      14m

Запишите внешний IP-адрес балансировщика нагрузки, так как он понадобится вам на следующем шаге.

Примечание. По умолчанию служба Nginx Ingress LoadBalancer имеет для service.spec.externalTrafficPolicy значение Local, которое направляет весь трафик балансировщика нагрузки на узлы, на которых запущены Nginx Ingress Pods. Другие узлы будут преднамеренно не проходить проверки работоспособности балансировщика нагрузки, чтобы входящий трафик не направлялся на них. Политики внешнего трафика выходят за рамки этого руководства, но чтобы узнать больше, вы можете обратиться к Source IP for Services with Type=LoadBalancer из официальной документации Kubernetes.

Этот балансировщик нагрузки получает трафик через порты HTTP и HTTPS 80 и 443 и перенаправляет его в модуль Ingress Controller. Контроллер входящего трафика затем направит трафик на соответствующую серверную службу.

Теперь мы можем направить наши DNS-записи на этот внешний балансировщик нагрузки и создать несколько входящих ресурсов для реализации правил маршрутизации трафика.

Шаг 3 — Создание входящего ресурса

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

В этом руководстве мы будем использовать тестовый домен example.com. Вы должны заменить это доменным именем, которым владеете.

Сначала мы создадим простое правило для маршрутизации трафика, направленного на echo1.example.com, на серверную службу echo1, а трафика, направленного на echo2.example.com< /mark> в серверную службу echo2.

Начните с открытия файла echo_ingress.yaml в вашем любимом редакторе:

  1. nano echo_ingress.yaml

Вставьте следующее определение входа:

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

Закончив редактирование правил Ingress, сохраните и закройте файл.

Здесь мы указали, что хотим создать входящий ресурс с именем echo-ingress и маршрутизировать трафик на основе заголовка узла. Заголовок узла HTTP-запроса указывает доменное имя целевого сервера. Чтобы узнать больше о заголовках запросов хоста, обратитесь к примеру Mozilla Developer Network.com будет перенаправлен на серверную часть echo2.

Теперь вы можете создать Ingress с помощью kubectl:

  1. kubectl apply -f echo_ingress.yaml

Вы увидите следующий вывод, подтверждающий создание Ingress:

Output
ingress.networking.k8s.io/echo-ingress created

Чтобы протестировать Ingress, перейдите к службе управления DNS и создайте записи A для echo1.example.com и echo2.example.com, указывающие на внешний IP-адрес балансировщика нагрузки DigitalOcean. Внешний IP-адрес балансировщика нагрузки — это внешний IP-адрес службы ingress-nginx, который мы получили на предыдущем шаге. Если вы используете DigitalOcean для управления записями DNS вашего домена, обратитесь к разделу «Как управлять записями DNS», чтобы узнать, как создавать записи A.

Создав необходимые DNS-записи echo1.example.com и echo2.example.com, вы можете протестировать Ingress Controller и Resource, которые вы создали, используя curl утилита командной строки.

На локальном компьютере curl сервис echo1:

  1. curl echo1.example.com

Вы должны получить следующий ответ от службы echo1:

Output
echo1

Это подтверждает, что ваш запрос к echo1.example.com правильно направляется через вход Nginx в серверную службу echo1.

Теперь выполните тот же тест для службы echo2:

  1. curl echo2.example.com

Вы должны получить следующий ответ от службы echo2:

Output
echo2

Это подтверждает, что ваш запрос к echo2.example.com правильно направляется через вход Nginx в серверную службу echo2.

На данный момент вы успешно настроили минимальный Nginx Ingress для выполнения маршрутизации на основе виртуального хоста. На следующем шаге мы установим cert-manager для предоставления сертификатов TLS для нашего Ingress и включения более безопасного протокола HTTPS.

Шаг 4 — Установка и настройка Cert-Manager

На этом шаге мы установим v1.7.1 cert-manager в наш кластер. cert-manager — это надстройка Kubernetes, которая предоставляет сертификаты TLS от издателей.

Установите cert-manager и инструкции по его установке. Обратите внимание, что будет создано пространство имен с именем cert-manager, в котором будут созданы объекты cert-manager:

  1. kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

Вы должны увидеть следующий вывод:

Output
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
. . .
deployment.apps/cert-manager-webhook created
mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created
validatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

Чтобы проверить нашу установку, проверьте пространство имен cert-manager для запущенных модулей:

  1. kubectl get pods --namespace cert-manager



Output
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-578cd6d964-hr5v2              1/1     Running   0          99s
cert-manager-cainjector-5ffff9dd7c-f46gf   1/1     Running   0          100s
cert-manager-webhook-556b9d7dfd-wd5l6      1/1     Running   0          99s

Это означает, что установка cert-manager прошла успешно.

Прежде чем мы начнем выдавать сертификаты для наших доменов echo1.example.com и echo2.example.com, нам нужно создать эмитента, который указывает центр сертификации, из которого был подписан x509. можно получить сертификаты. В этом руководстве мы будем использовать центр сертификации Let’s Encrypt, который предоставляет бесплатные сертификаты TLS и предлагает как промежуточный сервер для тестирования конфигурации вашего сертификата, так и рабочий сервер для развертывания проверяемых сертификатов TLS.

Давайте создадим тестовый ClusterIssuer, чтобы убедиться, что механизм предоставления сертификатов работает правильно. ClusterIssuer не ограничен пространством имен и может использоваться ресурсами сертификата в любом пространстве имен.

Откройте файл с именем staging_issuer.yaml в своем любимом текстовом редакторе:

nano staging_issuer.yaml

Вставьте следующий манифест ClusterIssuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
 namespace: cert-manager
spec:
 acme:
   # The ACME server URL
   server: https://acme-staging-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email: your_email_address_here
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-staging
   # Enable the HTTP-01 challenge provider
   solvers:
   - http01:
       ingress:
         class:  nginx

Здесь мы указываем, что хотим создать ClusterIssuer с именем letsencrypt-staging и использовать промежуточный сервер Let’s Encrypt. Позже мы будем использовать рабочий сервер для развертывания наших сертификатов, но рабочий сервер ограничивает скорость запросов к нему, поэтому в целях тестирования вы должны использовать промежуточный URL-адрес.

Затем мы указываем адрес электронной почты для регистрации сертификата и создаем Kubernetes Issuers.

Разверните ClusterIssuer с помощью kubectl:

  1. kubectl create -f staging_issuer.yaml

Вы должны увидеть следующий вывод:

Output
clusterissuer.cert-manager.io/letsencrypt-staging created

Теперь мы повторим этот процесс, чтобы создать рабочий ClusterIssuer. Обратите внимание, что сертификаты будут создаваться только после аннотирования и обновления ресурса Ingress, подготовленного на предыдущем шаге.

Откройте файл с именем prod_issuer.yaml в своем любимом редакторе:

nano prod_issuer.yaml

Вставьте следующий манифест:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: your_email_address_here
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx

Обратите внимание на другой URL-адрес сервера ACME и имя секретного ключа letsencrypt-prod.

Когда вы закончите редактирование, сохраните и закройте файл.

Разверните этот эмитент с помощью kubectl:

  1. kubectl create -f prod_issuer.yaml

Вы должны увидеть следующий вывод:

Output
clusterissuer.cert-manager.io/letsencrypt-prod created

Теперь, когда мы создали промежуточный и рабочий ClusterIssuers Let's Encrypt, мы готовы изменить созданный выше ресурс Ingress и включить шифрование TLS для echo1.example.com и echo2. пути example.com.

Если вы используете DigitalOcean Kubernetes, вам сначала необходимо реализовать шаг 6.

Шаг 5 — Включение связи модуля через балансировщик нагрузки (необязательно)

Прежде чем предоставлять сертификаты от Let’s Encrypt, cert-manager сначала выполняет самопроверку, чтобы убедиться, что Let’s Encrypt может связаться с модулем cert-manager, который проверяет ваш домен. Чтобы эта проверка прошла в DigitalOcean Kubernetes, вам необходимо включить связь Pod-Pod через балансировщик нагрузки Nginx Ingress.

Для этого мы создадим DNS-запись A, указывающую на внешний IP-адрес облачного балансировщика нагрузки, и аннотируем манифест Nginx Ingress Service этим субдоменом.

Начните с перехода к службе управления DNS и создайте запись A для обходного решения.example.com, указывающую на внешний IP-адрес балансировщика нагрузки DigitalOcean. Внешний IP-адрес Load Balancer — это внешний IP-адрес для службы ingress-nginx, который мы получили на шаге 2. Если вы используете DigitalOcean для управления записями DNS вашего домена, обратитесь к разделу How to Manage DNS Records, чтобы узнать, как создавать записи A. Здесь мы используем субдомен обходной путь, но вы можете использовать любой субдомен, какой пожелаете.

Теперь, когда вы создали запись DNS, указывающую на балансировщик нагрузки Ingress, аннотируйте службу Ingress LoadBalancer с помощью аннотации do-loadbalancer-hostname. Откройте файл с именем ingress_nginx_svc.yaml в своем любимом редакторе и вставьте в него следующий манифест LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: 'true'
    service.beta.kubernetes.io/do-loadbalancer-hostname: "workaround.example.com"
  labels:
    helm.sh/chart: ingress-nginx-4.0.6
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/version: 1.1.1
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: controller
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: http
    - name: https
      port: 443
      protocol: TCP
      targetPort: https
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/component: controller

Этот манифест службы был извлечен из полного файла манифеста Nginx Ingress, который вы установили на шаге 2. Обязательно скопируйте манифест службы, соответствующий установленной вами версии Nginx Ingress; в этом руководстве это 1.1.1. Также не забудьте установить в аннотации do-loadbalancer-hostname домен workaround.example.com.

Когда вы закончите, сохраните и закройте файл.

Измените работающую службу ingress-nginx-controller с помощью kubectl apply:

kubectl apply -f ingress_nginx_svc.yaml

Вы должны увидеть следующий вывод:

Output
service/ingress-nginx-controller configured

Это подтверждает, что вы аннотировали службу ingress-nginx-controller, и теперь поды в вашем кластере могут взаимодействовать друг с другом с помощью этого балансировщика нагрузки ingress-nginx-controller.

Шаг 6 — Выдача промежуточных и производственных сертификатов Let’s Encrypt

Чтобы выпустить промежуточный сертификат TLS для наших доменов, мы аннотируем echo_ingress.yaml с помощью ClusterIssuer, созданного на шаге 4. При этом будет использоваться ingress-shim для автоматического создания и выдачи сертификаты для доменов, указанных в манифесте Ingress.

Откройте echo_ingress.yaml в своем любимом редакторе:

  1. nano echo_ingress.yaml

Добавьте следующее в манифест ресурса Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - echo1.example.com
    - echo2.example.com
    secretName: echo-tls
  rules:
    - host: echo1.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo1
                port:
                  number: 80
    - host: echo2.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo2
                port:
                  number: 80

Здесь мы добавляем аннотацию, чтобы установить для диспетчера сертификатов ClusterIssuer значение letsencrypt-staging, тестовый сертификат ClusterIssuer, созданный на шаге 4. Мы также добавляем аннотацию, описывающую тип входа, в данном случае nginx.

Мы также добавляем блок tls, чтобы указать хосты, для которых мы хотим получить сертификаты, и указать secretName. Этот секрет будет содержать закрытый ключ TLS и выданный сертификат. Обязательно замените example.com доменом, для которого вы создали записи DNS.

Когда вы закончите вносить изменения, сохраните и закройте файл.

Теперь мы отправим это обновление в существующий объект Ingress с помощью kubectl apply:

  1. kubectl apply -f echo_ingress.yaml

Вы должны увидеть следующий вывод:

Output
ingress.networking.k8s.io/echo-ingress configured

Вы можете использовать kubectl описать, чтобы отслеживать состояние изменений Ingress, которые вы только что применили:

  1. kubectl describe ingress



Output
Events:
  Type    Reason             Age               From                      Message
  ----    ------             ----              ----                      -------
  Normal  UPDATE             6s (x3 over 80m)  nginx-ingress-controller  Ingress default/echo-ingress
  Normal  CreateCertificate  6s                cert-manager              Successfully created Certificate "echo-tls"

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

  1. kubectl describe certificate

Вы должны увидеть следующий вывод в разделе Events:

Output
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Requested  64s    cert-manager  Created new CertificateRequest resource "echo-tls-vscfw"
  Normal  Issuing    40s    cert-manager  The certificate has been successfully issued

Это подтверждает, что сертификат TLS был успешно выдан и шифрование HTTPS теперь активно для двух настроенных доменов.

Теперь мы готовы отправить запрос на внутренний сервер echo, чтобы проверить правильность работы HTTPS.

Выполните следующую команду wget, чтобы отправить запрос на echo1.example.com и вывести заголовки ответа на STDOUT:

  1. wget --save-headers -O- echo1.example.com

Вы должны увидеть следующий вывод:

Output
. . .
HTTP request sent, awaiting response... 308 Permanent Redirect
. . .
ERROR: cannot verify echo1.example.com's certificate, issued by ‘ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=(STAGING) Artificial Apricot R3,O=(STAGING) Let's Encrypt,C=US’:
  Unable to locally verify the issuer's authority.
To connect to echo1.example.com insecurely, use `--no-check-certificate'.

Это указывает на то, что HTTPS успешно включен, но сертификат не может быть проверен, так как это поддельный временный сертификат, выданный промежуточным сервером Let’s Encrypt.

Теперь, когда мы проверили, что все работает с использованием этого временного поддельного сертификата, мы можем развернуть рабочие сертификаты для двух хостов echo1.example.com и echo2.example.com. . Для этого мы будем использовать letsencrypt-prod ClusterIssuer.

Обновите echo_ingress.yaml, чтобы использовать letsencrypt-prod:

  1. nano echo_ingress.yaml

Внесите в файл следующие изменения:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - echo1.example.com
    - echo2.example.com
    secretName: echo-tls
  rules:
    - host: echo1.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo1
                port:
                  number: 80
    - host: echo2.example.com
      http:
        paths:
          - pathType: Prefix
            path: "/"
            backend:
              service:
                name: echo2
                port:
                  number: 80

Здесь мы обновляем имя ClusterIssuer на letsencrypt-prod.

Когда вы будете удовлетворены своими изменениями, сохраните и закройте файл.

Внесите изменения с помощью kubectl apply:

  1. kubectl apply -f echo_ingress.yaml



Output
ingress.networking.k8s.io/echo-ingress configured

Подождите пару минут, пока рабочий сервер Let’s Encrypt выдаст сертификат. Вы можете отслеживать его ход, используя kubectl description для объекта certificate:

  1. kubectl describe certificate echo-tls

Как только вы увидите следующий вывод, сертификат был успешно выпущен:

Output
 Normal  Issuing    28s                 cert-manager  Issuing certificate as Secret was previously issued by ClusterIssuer.cert-manager.io/letsencrypt-staging
  Normal  Reused     28s                 cert-manager  Reusing private key stored in existing Secret resource "echo-tls"
  Normal  Requested  28s                 cert-manager  Created new CertificateRequest resource "echo-tls-49gmn"
  Normal  Issuing    2s (x2 over 4m52s)  cert-manager  The certificate has been successfully issued

Теперь мы выполним тест с помощью curl, чтобы убедиться, что HTTPS работает правильно:

  1. curl echo1.example.com

Вы должны увидеть следующее:

Output
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.15.9</center>
</body>
</html>

Это указывает на то, что HTTP-запросы перенаправляются для использования HTTPS.

Запустите curl на https://echo1.example.com:

  1. curl https://echo1.example.com

Теперь вы должны увидеть следующий вывод:

Output
echo1

Вы можете запустить предыдущую команду с подробным флагом -v, чтобы глубже изучить рукопожатие сертификата и проверить информацию о сертификате.

На данный момент вы успешно настроили HTTPS, используя сертификат Let’s Encrypt для вашего Nginx Ingress.

Заключение

В этом руководстве вы настроите Nginx Ingress для балансировки нагрузки и маршрутизации внешних запросов к серверным службам внутри вашего кластера Kubernetes. Вы также защитили Ingress, установив поставщик сертификатов cert-manager и настроив сертификат Let’s Encrypt для двух путей хоста.

Существует множество альтернатив Nginx Ingress Controller. Чтобы узнать больше, обратитесь к контроллерам Ingress из официальной документации Kubernetes.

Руководство по развертыванию Nginx Ingress Controller с помощью диспетчера пакетов Helm Kubernetes см. в статье Как настроить Nginx Ingress в DigitalOcean Kubernetes с помощью Helm.