Как настроить Nginx Ingress с Cert-Manager в DigitalOcean Kubernetes

Введение

Сущности Ingress в Kubernetes обеспечивают гибкую маршрутизацию внешнего трафика кластера Kubernetes среди служб внутри кластера. Это достигается с помощью ресурсов Ingress, которые определяют правила маршрутизации трафика HTTP и HTTPS для служб Kubernetes, и контроллеров Ingress, которые реализуют правила порседством балансировки нагрузки трафика и его перенаправления на соответствующие службы серверной части. В число популярных контроллеров Ingress входят Nginx, Contour, HAProxy и Traefik. Сущности Ingress — это более эффективная и гибкая альтернатива настройке множеству разных объектов служб LoadBalancer, каждый из которых использует собственный выделенный балансировщик нагрузки.

В этом руководстве мы настроим контроллер Nginx Ingress, обслуживаемый Kubernetes, и создадим несколько ресурсов Ingress для маршуртизации трафика на фиктивные серверные службы. После настройки Ingress мы установим в наш кластер cert-manager для управления и распределения сертификатами TLS для шифрования трафика HTTP в Ingress. В этом руководстве не используется диспетчер пакетов Helm. Информацию о развертывании контроллера Nginx Ingress с помощью Helm можно найти в документе Настройка Nginx Ingress в DigitalOcean Kubernetes с помощью Helm.

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

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

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

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

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

Перед развертыванием контроллера Ingress мы создадим и развернем две фиктивных службы echo, на которые будем перенаправлять внешний трафик с помощью Ingress. Службы echo будут запускать контейнер hashicorp/http-echo, возвращающий страницу с текстовой строкой, переданной при запуске веб-сервера. Дополнительную информацию по http-echo можно получить в GitHub Repo, а дополнительную информацию о службах Kubernetes можно найти в разделе Services в официальной документации Kubernetes.

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

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 Label Selector. Мы указываем, что в развертывании должно быть 2 копии пода, и что поды должны запускать контейнер echo1 с образом hashicorp/http-echo. Мы передаем параметр text и устанавливаем для него значение echo1, так что веб-сервер http-echo возвращает echo1. Наконец, мы открываем порт 5678 в контейнере подов.

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

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

kubectl apply -f echo1.yaml

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

Output
service/echo1 created
deployment.apps/echo1 created

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

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 доступна по внутреннему IP-адресу 10.245.222.129 на порту 80. Она будет перенаправлять трафик в порт контейнера 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:

kubectl apply -f echo2.yaml

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

Output
service/echo2 created
deployment.apps/echo2 created

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

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.

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

На этом шаге мы развернем версию v0.26.1 контроллера Nginx Ingress, обслуживаемого Kubernetes. Существует несколько контроллеров Nginx Ingress. Сообщество Kubernetes обслуживает контроллер, используемый в этом обучающем модуле, а Nginx Inc. обслуживает kubernetes-ingress. Указания этого обучающего модуля основаны на приведенных в официальном руководстве по установке контроллера Kubernetes Nginx Ingress.

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

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

Для начала мы создадим необходимые ресурсы Kubernetes для контроллера Nginx Ingress. В их число входят карты ConfigMaps, содержащие конфигурацию контроллера, роли системы RBAC, предоставляющие контроллеру доступ к API Kubernetes, и фактическое развертывание контроллера Ingress, использующее версию 0.26.1 образа контроллера Nginx Ingress. Чтоб просмотреть полный список требуемых ресурсов, ознакомьтесь с манифестом репозитория контроллера Kubernetes Nginx Ingress на GitHub.

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

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.26.1/deploy/static/mandatory.yaml

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

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

Output
namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.apps/nginx-ingress-controller created

На этом экране результатов приведен удобный обзор всех объектов контроллера Ingress, созданных из манифеста mandatory.yaml.

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

Для создания службы LoadBalancer мы снова используем команду kubectl apply с файлом манифеста, содержащим определение службы:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.26.1/deploy/static/provider/cloud-generic.yaml

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

Output
service/ingress-nginx created

Подтвердите запуск подов контроллера Ingress:

kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx

Output
NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx   nginx-ingress-controller-7fb85bc8bb-lnm6z   1/1     Running   0          2m42s

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

kubectl get svc --namespace=ingress-nginx

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

Output
NAME            TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx   LoadBalancer   10.245.247.67   203.0.113.0   80:32486/TCP,443:32096/TCP   20h

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

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

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

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

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

В этом обучающем модуле мы используем тестовый домен example.com. Вы должны заменить его вашим доменным именем.

Вначале мы создадим простое правило для перенаправления адресованного echo1.example.com трафика на серверную службу echo1 и адресованного echo2.example.com трафика на серверную службу echo2.

Для начала откройте файл echo_ingress.yaml в предпочитаемом редакторе:

nano echo_ingress.yaml

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  rules:
  - host: echo1.example.com
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.example.com
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

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

Мы указали, что хотим создать ресурс Ingress с именем echo-ingress и перенаправлять трафик на базе заголовка Host. В запросе HTTP заголовок Host указывает доменное имя целевого сервера. Дополнительную информацию о заголовках Host можно найти на странице определений Mozilla Developer Network. Запросы хоста echo1.example.com будут перенаправляться на серверную службу echo1, настроенную на шаге 1, а запросы хоста echo2.example.com будут перенаправляться на серверную службу echo2.

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

kubectl apply -f echo_ingress.yaml

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

Output
ingress.extensions/echo-ingress created

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

После создания необходимых записей echo1.example.com и echo2.example.com вы можете протестировать контроллер Ingress и созданные ресурсы с помощью утилиты командной строки curl.

Выполните команду curl для службы echo1 на локальном компьютере:

curl echo1.example.com

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

Output
echo1

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

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

curl echo2.example.com

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

Output
echo2

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

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

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

На этмо шаге мы произведем установку cert-manager в нашем кластере. cert-manager — это служба Kubernetes, предоставляющая сертификаты TLS от Let’s Encrypt и других центров сертификации и управляющая их жизненными циклами. Сертификаты можно запрашивать и настраивать посредством аннотации ресурсов Ingress с помощью аннотации ert-manager.io/issuer с добавлением раздела tls в спецификацию Ingress и настройкой одного или нескольких элементов Issuer или ClusterIssuer для определения предпочитаемого центра сертификации. Дополнительную информацию об объектах Issuer и ClusterIssuer можно найти в официальной документации cert-manager по элементам Issuer.

Перед установкой cert-manager мы создадим пространство имен для его выполнения:

kubectl create namespace cert-manager

Далее мы выполним установку cert-manager и его определений персонализированных ресурсов (CRD), таких как Issuer и ClusterIssuer. Для этого нужно использовать apply для применения манифеста непосредственно из репозитория cert-manager на GitHub:

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.12.0/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 на наличие работающих подов:

kubectl get pods --namespace cert-manager

Output
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c47f46f57-jknnx              1/1     Running   0          27s
cert-manager-cainjector-6659d6844d-j8cbg   1/1     Running   0          27s
cert-manager-webhook-547567b88f-qks44      1/1     Running   0          27s

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

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

Создадим тестовый элемент Issuer, чтобы проверить правильность работы механизма распределения сертификатов. Откройте файл с именем staging_issuer.yaml в своем любимом текстовом редакторе:

nano staging_issuer.yaml

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

apiVersion: cert-manager.io/v1alpha2
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 с именем letsencrypt-staging для сохранения закрытого ключа учетной записи ACME. Также мы активируем механизм вызовов HTTP-01. Дополнительную информацию об этих параметрах можно найти в официальной документации cert-manager по элементам Issuer.

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

kubectl create -f staging_issuer.yaml

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

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

Теперь мы создали элемент Issuer для сервера размещения Let’s Encrypt и готовы изменить созданный выше ресурс Ingress и активировать шифрование TLS для путей echo1.example.com и echo2.example.com.

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

nano echo_ingress.yaml

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - echo1.hjdo.net
    - echo2.hjdo.net
    secretName: echo-tls
  rules:
  - host: echo1.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Здесь мы добавим несколько аннотаций для указания класса Ingress.class, определяющего контроллер Ingress, который должен использоваться для реализации правил Ingress. Кроме того, мы определим для cluster-issuer элемент сертификации letsencrypt-staging, который мы только что создали.

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

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

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

kubectl apply -f echo_ingress.yaml

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

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

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

kubectl describe ingress

Output
Events:
  Type    Reason             Age               From                      Message
  ----    ------             ----              ----                      -------
  Normal  CREATE             14m               nginx-ingress-controller  Ingress default/echo-ingress
  Normal  CreateCertificate  67s   cert-manager              Successfully created Certificate "echo-tls"
  Normal  UPDATE             53s   nginx-ingress-controller  Ingress default/echo-ingress

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

kubectl describe certificate

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

Output
Events:
  Type    Reason         Age   From          Message
  ----    ------         ----  ----          -------
  Normal  GeneratedKey  2m12s  cert-manager  Generated a new private key
  Normal  Requested     2m12s  cert-manager  Created new CertificateRequest resource "echo-tls-3768100355"
  Normal  Issued        47s    cert-manager  Certificate issued successfully

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

Теперь мы готовы отправить запрос на сервер echo для тестирования работы HTTPS.

Запустите следующую команду wget для отправки запроса на echo1.example.com и распечатайте заголовки ответов в STDOUT:

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 ‘CN=Fake LE Intermediate X1’:
  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.

Шаг 5 — Развертывание элемента Issuer в производственной среде

На этом шаге мы изменим процедуру, используемую для выделения фиктивных сертификатов, и генерируем действительный производственный сертификат для наших хостов Ingress.

Вначале мы создадим производственный сертификат ClusterIssuer.

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

nano prod_issuer.yaml

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

apiVersion: cert-manager.io/v1alpha2
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.

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

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

kubectl create -f prod_issuer.yaml

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

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

Обновите echo_ingress.yaml для использования нового элемента Issuer:

nano echo_ingress.yaml

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

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - echo1.hjdo.net
    - echo2.hjdo.net
    secretName: echo-tls
  rules:
  - host: echo1.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Здесь мы изменяем имя ClusterIssuer на letsencrypt-prod.

После внесения изменений сохраните и закройте файл.

Разверните изменения с помощью команды kubectl apply:

kubectl apply -f echo_ingress.yaml

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

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

kubectl describe certificate echo-tls

Следующий экран результатов означает, что сертификат успешно установлен:

Output
Events:
  Type    Reason        Age                  From          Message
  ----    ------        ----                 ----          -------
  Normal  GeneratedKey  8m10s                cert-manager  Generated a new private key
  Normal  Requested     8m10s                cert-manager  Created new CertificateRequest resource "echo-tls-3768100355"
  Normal  Requested     35s                  cert-manager  Created new CertificateRequest resource "echo-tls-4217844635"
  Normal  Issued        10s (x2 over 6m45s)  cert-manager  Certificate issued successfully

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

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:

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. Дополнительную информацию можно найти в разделе «Контроллеры Ingress» в официальной документации Kubernetes.

Информацию о развертывании контроллера Nginx Ingress с помощью диспетчера пакетов Helm Kubernetes можно найти в документе Настройка Nginx Ingress в DigitalOcean Kubernetes с помощью Helm.