Как настроить 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.

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

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

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

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

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

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

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

  • nano echo1.yaml

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

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 create с флагом -f, указав только что сохраненный файл в качестве параметра:

  • kubectl create -f echo1.yaml

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

Outputservice/echo1 created deployment.apps/echo1 created 

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

  • kubectl get svc echo1

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

OutputNAME      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:

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 create -f echo2.yaml

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

Outputservice/echo2 created deployment.apps/echo2 created 

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

  • kubectl get svc

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

OutputNAME         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.24.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, предоставляющие контроллеру доступ Kubernetes API, и фактическое развертывание контроллера Ingress, использующее версию 0.24.1 образа контроллера Nginx Ingress. Чтоб просмотреть полный список требуемых ресурсов, ознакомьтесь с манифестом репозитория контроллера Kubernetes Nginx Ingress на GitHub.

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

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

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

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

Outputnamespace/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.extensions/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.24.1/deploy/provider/cloud-generic.yaml

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

Outputservice/ingress-nginx created 

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

  • kubectl get svc --namespace=ingress-nginx

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

OutputNAME            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-адрес балансировщика нагрузки, поскольку он потребуется вам позднее.

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

Этот балансировщик нагрузки принимает трафик на портах 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:

echo_ingress.yaml

apiVersion: extensions/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:

Outputingress.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:

Outputecho1 

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

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

  • curl echo2.example.com

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

Outputecho2 

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

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

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

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

Примечание. Перед установкой cert-manager убедитесь, что вы используете версию Helm 2.12.1 или более позднюю версию. Чтобы проверить установленную версию Helm, запустите команду helm version на локальном компьютере.

Прежде чем использовать Helm для установки cert-manager в нашем кластере, нам нужно создать собственные определения ресурсов (CRD) для cert-manager. Используйте для их создания команду apply, чтобы применить их непосредственно из репозитория cert-manager на GitHub:

  • kubectl apply
  • -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

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

Outputcustomresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created 

Теперь мы добавим ярлык пространства имен kube-system, куда мы устанавливаем cert-manager, чтобы обеспечить расширенную проверку ресурсов с помощью webhook:

  • kubectl label namespace kube-system certmanager.k8s.io/disable-validation="true"

Теперь мы добавим репозиторий Jetstack Helm в Helm. Этот репозиторий содержит таблицу Helm для cert-manager.

  • helm repo add jetstack https://charts.jetstack.io

Наконец, мы установим таблицу в пространство имен kube-system:

  • helm install --name cert-manager --namespace kube-system jetstack/cert-manager --version v0.8.0

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

Output. . . NOTES: cert-manager has been deployed successfully!  In order to begin issuing certificates, you will need to set up a ClusterIssuer or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).  More information on the different types of issuers and how to configure them can be found in our documentation:  https://cert-manager.readthedocs.io/en/latest/reference/issuers.html  For information on how to configure cert-manager to automatically provision Certificates for Ingress resources, take a look at the `ingress-shim` documentation:  https://cert-manager.readthedocs.io/en/latest/reference/ingress-shim.html 

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

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

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

nano staging_issuer.yaml 

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

staging_issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1 kind: ClusterIssuer metadata:  name: letsencrypt-staging 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    http01: {} 

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

Затем мы укажем адрес электронной почты для регистрации сертификата и создадим секрет Kubernetes с именем letsencrypt-staging для сохранения закрытого ключа учетной записи ACME. Также мы активируем механизм вызовов HTTP-01. Дополнительную информацию об этих параметрах можно найти в официальной документации cert-manager по элементам Issuer.

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

  • kubectl create -f staging_issuer.yaml

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

Outputclusterissuer.certmanager.k8s.io/letsencrypt-staging created 

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

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

  • nano echo_ingress.yaml

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

echo_ingress.yaml

apiVersion: extensions/v1beta1 kind: Ingress metadata:   name: echo-ingress   annotations:       kubernetes.io/ingress.class: nginx     certmanager.k8s.io/cluster-issuer: letsencrypt-staging spec:   tls:   - hosts:     - echo1.example.com     - echo2.example.com     secretName: letsencrypt-staging   rules:   - host: echo1.example.com     http:       paths:       - backend:           serviceName: echo1           servicePort: 80   - host: echo2.example.com     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

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

Outputingress.extensions/echo-ingress configured 

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

  • kubectl describe ingress
OutputEvents:   Type    Reason             Age               From                      Message   ----    ------             ----              ----                      -------   Normal  CREATE             14m               nginx-ingress-controller  Ingress default/echo-ingress   Normal  UPDATE             1m (x2 over 13m)  nginx-ingress-controller  Ingress default/echo-ingress   Normal  CreateCertificate  1m                cert-manager              Successfully created Certificate "letsencrypt-staging" 

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

  • kubectl describe certificate

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

OutputEvents:   Type    Reason         Age   From          Message   ----    ------         ----  ----          -------   Normal  Generated      63s   cert-manager  Generated new private key   Normal  OrderCreated   63s   cert-manager  Created Order resource "letsencrypt-staging-147606226"   Normal  OrderComplete  19s   cert-manager  Order "letsencrypt-staging-147606226" completed successfully   Normal  CertIssued     18s   cert-manager  Certificate issued successfully 

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

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

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

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

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

OutputURL transformed to HTTPS due to an HSTS policy --2018-12-11 14:38:24--  https://echo1.example.com/ Resolving echo1.example.com (echo1.example.com)... 203.0.113.0 Connecting to echo1.example.com (echo1.example.net)|203.0.113.0|:443... connected. 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 

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

prod_issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1 kind: ClusterIssuer metadata:   name: letsencrypt-prod 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     http01: {} 

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

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

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

  • kubectl create -f prod_issuer.yaml

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

Outputclusterissuer.certmanager.k8s.io/letsencrypt-prod created 

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

  • nano echo_ingress.yaml

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

echo_ingress.yaml

apiVersion: extensions/v1beta1 kind: Ingress metadata:   name: echo-ingress   annotations:       kubernetes.io/ingress.class: nginx     certmanager.k8s.io/cluster-issuer: letsencrypt-prod spec:   tls:   - hosts:     - echo1.example.com     - echo2.example.com     secretName: letsencrypt-prod   rules:   - host: echo1.example.com     http:       paths:       - backend:           serviceName: echo1           servicePort: 80   - host: echo2.example.com     http:       paths:       - backend:           serviceName: echo2           servicePort: 80 

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

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

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

  • kubectl apply -f echo_ingress.yaml
Outputingress.extensions/echo-ingress configured 

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

  • kubectl describe certificate letsencrypt-prod

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

OutputEvents:   Type    Reason         Age   From          Message   ----    ------         ----  ----          -------   Normal  Generated      82s   cert-manager  Generated new private key   Normal  OrderCreated   82s   cert-manager  Created Order resource "letsencrypt-prod-2626449824"   Normal  OrderComplete  37s   cert-manager  Order "letsencrypt-prod-2626449824" completed successfully   Normal  CertIssued     37s   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

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

Outputecho1 

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

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

Заключение

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

Существует множество альтернатив использованию контроллера Nginx Ingress. Дополнительную информацию можно найти в разделе «Контроллеры Ingress» в официальной документации Kubernetes.