Table of Contents
Введение
Сущности 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 в Kubernetes с помощью Helm.
Предварительные требования
Прежде чем начать прохождение этого обучающего модуля, вам потребуется следующее:
- Кластер Kubernetes 1.10+ с включенным контролем доступа на основе ролей (RBAC)
- Инструмент командной строки
kubectl, установленный на локальном компьютере и настроенный для подключения к вашему кластеру. Дополнительную информацию об установкеkubectlможно найти в официальной документации.
- Доменное имя и записи DNS A, которые можно направить на балансировщик нагрузки the cloud provider, используемый Ingress. Если вы используете the cloud provider для управления записями 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
Вставьте в него следующий манифест служб и развертывания:
[label 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
Вы должны увидеть следующий результат:
[secondary_label Output]
service/echo1 created
deployment.apps/echo1 created
Убедитесь, что служба запустилась правильно, и проверьте наличие ClusterIP, внутреннего IP-адреса, по которому доступна служба:
kubectl get svc echo1
Вы должны увидеть следующий результат:
[secondary_label 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:
[label 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
Вы должны увидеть следующий результат:
[secondary_label Output]
service/echo2 created
deployment.apps/echo2 created
Еще раз проверьте, запущена ли служба:
kubectl get svc
Вы должны увидеть службы echo1 и echo2 с назначенными им значениями ClusterIP:
[secondary_label 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 в кластере Kubernetes, и контроллер создаст службу LoadBalancer, запускающую балансировщик нагрузки the cloud provider, на который будет направляться весь внешний трафик. Балансировщик нагрузки будет направлять внешний трафик на под контроллера 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.
Вы должны увидеть следующий результат:
[secondary_label 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, которая создаст балансировщик нагрузки the cloud provider для балансировки и маршрутизации трафика 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
Вы должны увидеть следующий результат:
[secondary_label Output]
service/ingress-nginx created
Подтвердите запуск подов контроллера Ingress:
kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx
[secondary_label Output]
NAMESPACE NAME READY STATUS RESTARTS AGE
ingress-nginx nginx-ingress-controller-7fb85bc8bb-lnm6z 1/1 Running 0 2m42s
Убедитесь, что балансировщик нагрузки the cloud provider создан успешно, получив детали службы с помощью команды kubectl:
kubectl get svc --namespace=ingress-nginx
Через несколько минут вы увидите внешний IP-адрес, соответствующий IP-адресу балансировщика нагрузки the cloud provider:
[secondary_label 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-адрес балансировщика нагрузки, поскольку он потребуется вам позднее.
Примечание. По умолчанию служба 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:
[label echo_ingress.yaml]
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:
[secondary_label Output]
ingress.extensions/echo-ingress created
Чтобы протестировать Ingress, перейдите в службу управления DNS и создайте записи A для echo1.example.com и echo2.example.com, указывающие на внешний IP-адрес балансировщика нагрузки the cloud provider. Внешний IP-адрес балансировщика нагрузки соответствует внешнему IP-адресу службы ingress-nginx, полученному на предыдущем шаге. Если вы используете the cloud provider для управления записями DNS вашего домена, руководство Управление записями DNS поможет вам научиться создавать записи класса A.
После создания необходимых записей echo1.example.com и echo2.example.com вы можете протестировать контроллер Ingress и созданные ресурсы с помощью утилиты командной строки curl.
Выполните команду curl для службы echo1 на локальном компьютере:
curl echo1.example.com
Вы должны получить следующий ответ от службы echo1:
[secondary_label Output]
echo1
Это подтверждает, что ваш запрос echo1.example.com правильно перенаправляется через Nginx ingress в серверную службу echo1.
Теперь повторите этот тест для службы echo2:
curl echo2.example.com
Вы должны получить следующий ответ от службы echo2:
[secondary_label 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
Вы должны увидеть следующий результат:
[secondary_label 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
[secondary_label 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:
[label staging_issuer.yaml]
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
Вы должны увидеть следующий результат:
[secondary_label 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 следующее:
[label 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-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
Вы должны увидеть следующий результат:
[secondary_label Output]
ingress.networking.k8s.io/echo-ingress configured
Вы можете использовать команду kubectl describe для отслеживания состояния изменений Ingress, которые вы только что применили:
kubectl describe ingress
[secondary_label 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:
[secondary_label 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
Вы должны увидеть следующий результат:
[secondary_label 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
Вставьте в него следующий манифест:
[label 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
Вы должны увидеть следующий результат:
[secondary_label Output]
clusterissuer.cert-manager.io/letsencrypt-prod created
Обновите echo_ingress.yaml для использования нового элемента Issuer:
nano echo_ingress.yaml
Внесите в файл следующее изменение:
[label 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
[secondary_label Output]
ingress.networking.k8s.io/echo-ingress configured
Подождите несколько минут, чтобы дать производственному серверу Let's Encrypt выдать сертификат. Вы можете отслеживать ход выполнения с помощью команды kubectl describe для объекта certificate:
kubectl describe certificate echo-tls
Следующий экран результатов означает, что сертификат успешно установлен:
[secondary_label 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
Вы должны увидеть следующее:
[secondary_label 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
Вы должны увидеть следующий результат:
[secondary_label 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 в Kubernetes с помощью Helm.
