Ingress
В Managed Kubernetes Ingress-контроллеры не предустанавливаются в кластеры. Для создания объектов Ingress нужно самостоятельно установить любой Ingress Controller.
Помимо самого приложения Ingress Controller будет создан сервис (Service) с типом LoadBalancer, то есть балансировщик нагрузки. Балансировщик будет входной точкой для доступа извне к приложениям в кластере. В таком случае при установке Ingress-контроллера нет необходимости дополнительно создавать внутренний балансировщик нагрузки.
Глоссарий
| Термин | Определение |
|---|---|
| Ingress | Механизм, обеспечивающий маршрутизацию входящего трафика на уровне приложения (L7), предоставляемый через Ingress-контроллер |
| Ingress-контроллер | Прокси-сервер, развернутый в кластере Managed Kubernetes. Специфика выбора контроллера зависит от требований приложений, размещенных в кластере Managed Kubernetes. Список существующих Ingress-контроллеров |
| Правила маршрутизации (Routing rules) | Правила проксирования входящего трафика от внешнего источника до сервисов внутри кластера Managed Kubernetes |
| Сервис (Service) | Служба Managed Kubernetes, развернутая в кластере и обеспечивающая функции сетевой балансировки нагрузки, объединяет несколько подов. У службы есть виртуальные IP-адреса, маршрутизируемые только в сети кластера |
| Под (Pod) | Группа из одного или нескольких контейнеров и совместно используемых ресурсов для этих контейнеров. Каждый под кластера Kubernetes имеет уникальный IP-адрес |
Подготовка к установке Ingress-контроллера
Перед установкой Ingress-контроллера:
Установка Ingress-контроллера
Рассмотрим установку базового Nginx-контроллера:
Проверьте, какие сервисы уже существуют в созданном пространстве имен (Namespace):
Добавьте репозиторий ingress-nginx из Kubeapps Hub:
Установите chart (поддерживает конфигурацию с Ingress-контроллером):
Проверьте сервисы еще раз, чтобы убедиться, что ingress-nginx-controller запущен:
Вывод должен выглядеть примерно так:
В панели управления в разделе Облачная платформа на вкладке Балансировщики появится новый балансировщик нагрузки.
Примечание: можно установить другой Ingress-контроллер по официальной инструкции.
Kubernetes tips & tricks: персонализированные страницы ошибок в NGINX Ingress
В данной статье я хочу рассказать про две возможности NGINX Ingress, связанные с отображением персонализированных страниц с ошибками, а также о существующих в них ограничениях и способах их обойти.
1. Изменение бэкенда по умолчанию
По умолчанию в NGINX Ingress используется default backend, который выполняет соответствующую функцию. Это означает, что при запросе Ingress’а с указанием хоста, которого нет в Ingress-ресурсах, мы получаем такую страницу с кодом ответа 404:
Для этого необходимо создать свой pod (deployment) и сервис с вашим приложением (пример реализации в YAML из репозитория ingress-nginx), которое будет отдаваться вместо default backend.
Вот небольшая иллюстрация:
2. Обработка HTTP-ошибок в приложении силами default backend
Другая ситуация — заканчивающиеся HTTP-ошибками (404, 500, 502…) запросы к приложению, в котором не обрабатываются такие ситуации (не генерируются соответствующие красивые страницы). Это может быть также вызвано желанием разработчиков отдавать одинаковые страницы ошибок во множестве приложений.
Для реализации данного кейса на серверной стороне нам необходимо:
Однако при разработке приложения для default backend и custom-http-errors нужно учесть важную особенность:
Дело в том, что при перенаправлении запроса в заголовках будет полезная информация с предыдущим кодом ответа и дополнительной информацией (полный их список доступен здесь).
Это означает, что вы сами должны позаботиться о корректном коде ответа. Вот пример из документации, как это работает.
Разным приложениям — разный default backend
Чтобы решение не было глобальным на весь кластер, а относилось только к конкретным приложениям, для начала надо проверить версию Ingress. Если она соответствует 0.23 или выше, воспользуйтесь «родными» аннотациями Ingress:
В таком случае ошибки 404 и 502 будут перенаправлены в сервис error-pages со всеми нужными заголовками.
В предыдущих версиях Ingress такой возможности не было (судьбоносный коммит в 0.23). И если у вас в кластере работает 2 совершенно разных приложения и вы хотите для каждого из них указывать разные default-backend-service и обработку различных кодов ошибок — для этого придётся воспользоваться workaround’ами, коих у нас два.
Иллюстрация в YAML:
Сервис для этого деплоя должен быть с типом ClusterIP.
При этом в приложении, где будем обрабатывать ошибку, в Ingress’е добавляем server-snippet или configuration-snippet со следующим содержимым:
Traefik как Ingress-контроллер для K8S
Не секрет, что у K8S отличное коммьюнити и в целом хорошая документация. В ней можно легко найти ответ на многие вопросы. Но как и любая другая документация, она не может покрывать абсолютно всё. В данной статье я попытаюсь привести подробную инструкцию, как развернуть и настроить Traefik для использования в качестве Ingress-контроллера.
Что такое Ingress?
Ingress — это объект API, который управляет внешним доступом к сервисам в кластере, главным образом через HTTP / HTTPS. Чтобы Ingress-ресурс заработал, нужен Ingress-контроллер. Если вы используете GCE, то контроллер Ingress уже развернут в мастер. Однако, если вы самостоятельно загрузили кластер, например с kops на AWS, вам нужно развернуть Ingress-контроллер самостоятельно. На minikube это решается включением надстройки Ingress.
Ingress-контроллеры
Роль Ingress-контроллера могут выполнять NGINX Ingress Controller, Kong, Octavia Ingress Controller и др. В этой статье мы рассмотрим такой инструмент как Traefik и посмотрим, как можно использовать его в качестве Ingress-контроллера для сервисов в кластере.
Зачем?
Traefik-компоненты
Traefik объявил о поддержке Kubernetes Ingress в версии 1.4. Однако недавно выпущенный Traefik 1.7 имеет опцию publishedService, которая умеет обновлять поле status в Ingress, чего не было в предыдущих версиях. Ниже представлен список компонентов, которые потребуются для работы.
Создайте:
Namespace
TLS Secret
(прим. пер. — в примере далее автор зачем-то дублирует один и тот же конфиг, актуальный конфиг смотрите в README-файле, представленном по ссылке ниже)
Сначала создайте сертификат:
Создайте сертификат TLS:
Для удобства я сделал README-файл с этими командами и выложил его в свой GitHub.
ConfigMap
EntryPoint http слушает :80 и не имеет дополнительных правил
EntryPoint https слушает :443 и содержит правило для подключения TLS-сертификатов.
ClusterRole
Последние 6 строк очень важны для корректной работы.
Deployment
Deployment довольно простой и понятный. Давайте коротко пройдемся по основным блокам:
Проверка работоспособности выполняется по 80 порту, как это было определено в ConfigMap.
Откройте порты для всех entryPoints, указанных в конфигурационном файле:
Service
Service (for Dashboard)
Ingress (for Dashboard)
Магия заключается в том, что проксирование защищенного трафика к Dashboard’у производится через сам Traefik. Управление Traefik в Ingress производится с помощью аннотаций Traefik:
Потребовалось всего 4 простые и понятные аннотации.
Было бы здорово, если бы это (прим. пер.: имеется в виду создание DNS-записей) производилось автоматически? Не проблема, я напишу об автоматическом создании DNS-записей в следующей статье.
Настройка распределенной трассировки в Kubernetes с OpenTracing, Jaeger и Ingress-NGINX
В эпоху, когда крупные компании используют более 500 микросервисов одновременно, важно иметь возможность быстро выяснить, из-за чего произошел сбой или снизилась производительность. Без специализированных инструментов это может быть похоже на поиск иголки в стоге сена.
В качестве примера мы будем использовать приложение Meow-Micro, специально созданное для этой статьи. Но вы можете развернуть собственные приложения, если захотите.
Что нам потребуется?
В этом руководстве предполагается, что вы понимаете код, написанный на Go, умеете использовать Ingress-nginx и знаете, как работают основные объекты Kubernetes, такие как Service и Deployment.
Если вы хотите освежить знания, воспользуйтесь этими материалами:
Запуск Kubernetes в Docker Desktop
Начнём с установки Docker Desktop, который позволяет не только запускать контейнеры, но и создать локальный кластер Kubernetes.
После установки Docker Desktop выполните следующие действия, чтобы создать кластер Kubernetes:
Нажмите на иконку Preferences
2. Выберете вкладку Kubernetes, установите флажок Enable Kubernetes и нажмите кнопку Apply & Restart
3. В появившемся окне нажмите кнопку Install и дождитесь пока установка завершится
4. Выберите пункт Kubernetes в панели задач
5. В контекстном меню выберите docker-desktop
6. Проверьте, что вы подключены к нужному кластеру
Установка Ingress-NGINX Controller
1. Воспользуйтесь командой из официального руководства для установки Ingress-NGINX Controller.
2. Проверьте, что установка Ingress Сontroller прошла успешно. Pods должны быть запущены и находятся в статусе Ready.
Важно: Если Pod находится в статусе Pending из-за нехватки ресурсов CPU/Memory, вы можете добавить ресурсы вашему кластеру в настройках Docker Desktop.
Установка Jaeger и настройка Ingress Controller
1. Вначале склонируйте репозиторий meow-micro, этот проект мы будем использовать во всех примерах.
2. В репозитории вы найдёте манифесты для jaeger-all-in-one. Установим Jaeger из этих манифестов.
3. Убедимся, что Jaeger запущен и готов к работе.
4. Пришло время настроить совместную работу Ingress-NGINX and Jaeger, для этого необходимо добавить параметры enable-opentracing и jaeger-collector-host в ingress-nginx-controller ConfigMap. В параметре jaeger-collector-host указываем имя сервиса Jaeger.
5. Убедимся, что в настройках Ingress Controller включен и настроен opentracing.
Jaeger и Ingress Controller успешно установлены и настроены. Самое время развернуть наши микросервисы!
Разворачиваем тестовое приложение
Подробная информация об использовании REST и GRPC с GoLang:
Тестовое приложение также содержит несколько дополнительных инструментов:
tracing.go
Получает параметры для настройки Jaeger из окружения, в котором запускается Helm для установки meow-client and meow-server.
client.go
Span — базовый элемент распределенной трассировки. Представляет собой описание некоего рабочего процесса (например, запроса к базе данных). Span’ы обычно содержат ссылки на другие span’ы, что позволяет объединять множество span’ов в Trace.
Trace — визуализация жизни запроса в процессе его перемещения по распределенной системе.
Подробную информацию о понятиях trace и span можно посмотреть в официальной документации.
Установка тестового приложения
Установить Helm v3 можно на любую операционную систему, например на macOS с помощью brew. Теперь мы готовы развернуть микросервисы в нашем кластере.
Воспользуемся Makefile из репозитория, чтобы развернуть тестовое приложение в кластере Kubernetes.
Проверим, что Pods обоих сервисов запустились и работают.
Просмотр данных трассировки
А теперь самое интересное! Взглянем на трассировку.
Откройте консоль Jaeger, указав в браузере адрес http://localhost:8081.
2. Отправим запрос нашему приложению.
4. Нажмите кнопку Find Traces.
5. Отобразятся все трассировки для nginx. Каждую из них можно развернуть, чтобы получить больше информации.
6. Теперь вы можете отслеживать, сколько времени занял каждый запрос.
И выводить дополнительную информацию по каждому запросу.
Не смотря на то, что этот небольшой пример даёт представление о том, что такое распределенная трассировка, увидеть всю её мощь можно только на реальных приложениях под нагрузкой.
Другие системы трассировки
Мы рассмотрели как использовать Jaeger для трассировки запросов Ingress-Nginx. Для этих целей можно также использовать Zipkin или DataDog.
Настройка Nginx Ingress в Kubernetes с помощью Helm
Kubernetes Ingress обеспечивает гибкий способ маршрутизации трафика от вашего кластера к внутренним сервисам Kubernetes. Ресурсы Ingress – это объекты Kubernetes, которые определяют правила маршрутизации трафика HTTP и HTTPS на сервисы. Чтобы они работали, нужен контроллер (Ingress Controller); его роль заключается в реализации правил при приеме трафика (скорее всего, через балансировщик нагрузки) и его направлении на соответствующие сервисы. Большинство контроллеров используют один глобальный балансировщик нагрузки для всех Ingress-ов, что более эффективно, чем создание индивидуального балансировщика для каждого сервиса.
Helm – менеджер пакетов для управления Kubernetes. Использование чартов Helm в Kubernetes предоставляет возможность настройки и управления жизненным циклом приложения Kubernetes (обновлениями, откатом и удалением).
В этом мануале мы настроим контроллер Nginx Ingress Controller, поддерживаемый Kubernetes, с помощью Helm. Затем мы создадим ресурс Ingress для маршрутизации трафика ваших доменов на тестовый бэкенд сервис Hello World. После настройки Ingress мы установим в кластер Cert-Manager, чтобы иметь возможность автоматически получать TLS сертификаты Let’s Encrypt для защиты Ingress-ов.
Требования
1: Настройка развертываний Hello World
В этом разделе перед развертыванием Nginx Ingress мы развернем простое приложение Hello World под названием hello-kubernetes, чтобы получить тестовые сервисы, на которые вы будете перенаправлять трафик. Чтобы в дальнейшем была возможность убедиться, что Nginx Ingress работает правильно, нужно развернуть его дважды с разными приветственными сообщениями, которые будут отображаться при доступе из браузера.
Хранить конфигурацию развертывания нужно на локальном компьютере. Первая конфигурация будет находиться в файле hello-kubernetes-first.yaml. Создайте его с помощью текстового редактора:
Добавьте следующие строки:
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-first
spec:
type: ClusterIP
ports:
— port: 80
targetPort: 8080
selector:
app: hello-kubernetes-first
—
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-first
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-first
template:
metadata:
labels:
app: hello-kubernetes-first
spec:
containers:
— name: hello-kubernetes
image: paulbouwer/hello-kubernetes:1.5
ports:
— containerPort: 8080
env:
— name: MESSAGE
value: Hello from the first deployment!
Эта конфигурация определяет развертывание и сервис. Развертывание состоит из трех реплик образа paulbouwer/hello-kubernetes:1.5 и переменной среды MESSAGE – ее значение будет отображаться при доступе к приложению. Сервис здесь предоставляет доступ к кластеру развертывания по порту 80.
Сохраните и закройте файл.
Затем создайте этот первый вариант приложения hello-kubernetes в Kubernetes, выполнив следующую команду:
Вы увидите такой вывод:
service/hello-kubernetes-first created
deployment.apps/hello-kubernetes-first created
Чтобы проверить создание сервиса, выполните команду:
kubectl get service hello-kubernetes-first
Вывод будет выглядеть так:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-kubernetes-first ClusterIP 10.245.85.236 80:31623/TCP 35s
Вы увидите, что недавно созданному сервису присвоен ClusterIP, а это означает, что он работает правильно. Весь трафик, отправленный на него, будет перенаправлен на выбранное развертывание через порт 8080. Теперь, когда вы развернули первый вариант приложения hello-kubernetes, можно поработать над вторым.
Откройте файл hello-kubernetes-second.yaml в редакторе:
Добавьте следующие строки:
apiVersion: v1
kind: Service
metadata:
name: hello-kubernetes-second
spec:
type: ClusterIP
ports:
— port: 80
targetPort: 8080
selector:
app: hello-kubernetes-second
—
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-kubernetes-second
spec:
replicas: 3
selector:
matchLabels:
app: hello-kubernetes-second
template:
metadata:
labels:
app: hello-kubernetes-second
spec:
containers:
— name: hello-kubernetes
image: paulbouwer/hello-kubernetes:1.5
ports:
— containerPort: 8080
env:
— name: MESSAGE
value: Hello from the second deployment!
Сохраните и закройте файл.
Этот вариант приложения имеет ту же структуру, что и предыдущая конфигурация; отличаются только имена развертываний и сервисов (чтобы избежать конфликтов) и текст сообщения.
Теперь создайте его в Kubernetes с помощью следующей команды:
Появится такой вывод:
service/hello-kubernetes-second created
deployment.apps/hello-kubernetes-second created
Убедитесь, что второй сервис запущен и работает:
kubectl get service
Вывод будет примерно таким:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-kubernetes-first ClusterIP 10.245.85.236 80:31623/TCP 54s
hello-kubernetes-second ClusterIP 10.245.99.130 80:30303/TCP 12s
kubernetes ClusterIP 10.245.0.1 443/TCP 5m
В выводе показан как сервис hello-kubernetes-first, так и hello-kubernetes-second, а это значит, что Kubernetes успешно создал их.
Итак, вы создали два развертывания приложения hello-kubernetes с сопутствующими сервисами. Каждое развертывание имеет свой набор сообщений в спецификации, что позволит вам различать их во время тестирования. На следующем этапе вы установите Nginx Ingress Controller.
2: Установка входного контроллера Ingress Kubernetes
Теперь вы установите поддерживаемый Kubernetes Nginx Ingress Controller с помощью Helm. Обратите внимание, есть несколько Nginx Ingress-ов.
Контроллер Nginx Ingress состоит из пода и сервиса. Под запускает контроллер, который постоянно опрашивает конечную точку /ingresses на API-сервере кластера на наличие обновлений для доступных ресурсов Ingress. Сервис имеет тип LoadBalancer. Через балансировщик трафик будет попадать в контроллер. Затем контроллер направит трафик к соответствующим сервисам, как определено в ресурсах Ingress.
Только сервис LoadBalancer знает IP-адрес вашего балансировщика нагрузки. Некоторым приложениям (таким как ExternalDNS) необходимо знать его IP-адрес, но они могут только читать конфигурацию Ingress. Контроллер можно настроить для публикации IP-адреса на каждом Ingress-е, для этого нужно добавить параметр controller.publishService.enabled со значением true в команду helm install. Рекомендуется включить этот параметр для поддержки приложений, которые могут зависеть от IP-адреса балансировщика нагрузки.
Чтобы установить Nginx Ingress Controller в ваш кластер, выполните следующую команду:
Эта команда устанавливает Nginx Ingress Controller из репозитория чартов stable, называет релиз nginx-ingress и присваивает параметру publishService значение true.
Вывод будет выглядеть так:
80:31305/TCP,443:30519/TCP 0s
nginx-ingress-default-backend ClusterIP 10.245.221.49 80/TCP 0s
==> v1/ServiceAccount
NAME SECRETS AGE
nginx-ingress 1 0s
==> v1beta1/ClusterRole
NAME AGE
nginx-ingress 0s
==> v1beta1/ClusterRoleBinding
NAME AGE
nginx-ingress 0s
==> v1beta1/Deployment
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-ingress-controller 0/1 1 0 0s
nginx-ingress-default-backend 0/1 1 0 0s
==> v1beta1/Role
NAME AGE
nginx-ingress 0s
==> v1beta1/RoleBinding
NAME AGE
nginx-ingress 0s
NOTES:
.
Helm зарегистрировал ресурсы, которые он создал в Kubernetes как часть установки чарта.
Вы можете увидеть, как появляется доступ к балансировщику, запустив команду:
Вы установили Ingress контроллер Nginx, поддерживаемый сообществом Kubernetes. Он будет направлять трафик HTTP и HTTPS от балансировщика нагрузки к соответствующим бэкенд сервисам, настроенным в ресурсах Ingress. На следующем этапе вы познакомитесь с развертываниями приложения hello-kubernetes с помощью этих ресурсов.
3: Настройка доступа к приложениям с помощью Ingress
Теперь пора создать Ingress ресурс и использовать его для демонстрации развертываний приложений hello-kubernetes на желаемых доменах. Затем мы протестируем приложение, открыв его через браузер.
Хранить Ingress мы будем в файле hello-kubernetes-ingress.yaml. Создайте его в редакторе:
Добавьте следующие строки в ваш файл:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
— host: hw1.example.com
http:
paths:
— backend:
serviceName: hello-kubernetes-first
servicePort: 80
— host: hw2.example.com
http:
paths:
— backend:
serviceName: hello-kubernetes-second
servicePort: 80
В приведенном выше коде определяется ресурс Ingress по имени hello-kubernetes-ingress. Затем указывается два правила хоста, так что hw1.example.com направляется на сервис hello-kubernetes-first, а hw2.example.com направляется на Сервис второго развертывания (hello-kubernetes-second).
Не забудьте заменить условные домены своими собственными, затем сохраните и закройте файл.
Создайте ресурс в Kubernetes, выполнив следующую команду:
Затем вам нужно убедиться, что ваши два домена указаны в балансировщике нагрузки через записи А. Это делается через DNS провайдера.
Теперь вы можете перейти к домену hw1.example.com в вашем браузере. Вы увидите следующее сообщение:
Hello from the first deployment!
Второй вариант приложения (hw2.example.com) покажет другое сообщение:
Hello from the second deployment!
Мы убедились, что Ingress Controller правильно направляет запросы (в этом случае от двух доменов к двум разным сервисам).
Вы создали и настроили ресурс Ingress для обслуживания развертываний приложений hello-kubernetes на ваших доменах. На следующем этапе мы настроим Cert-Manager, чтобы иметь возможность защитить ваши ресурсы с помощью бесплатных сертификатов TLS от Let’s Encrypt.
4: Защита доступа с помощью Cert-Manager
Чтобы обезопасить свои ресурсы Ingress, вы установите Cert-Manager, создадите ClusterIssuer для производства и измените конфигурацию Ingress, чтобы использовать сертификаты TLS. ClusterIssuer – это ресурс Cert-Manager в Kubernetes, которые предоставляют сертификаты TLS. После установки и настройки ваше приложение будет работать по HTTPS.
Перед установкой Cert-Manager в кластер через Helm нужно вручную применить требуемые CRD (Custom Resource Definitions, пользовательские определения ресурсов) из репозитория jetstack/cert-manager, выполнив следующую команду:
Вы получите такой вывод:
customresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created
Этот вывод показывает, что Kubernetes применил пользовательские ресурсы, необходимые для cert-manager.
Примечание: Если вы следовали этому руководству и выполнили требования, скорее всего, вы не создали пространство имен Kubernetes по имени cert-manager, поэтому вам не нужно будет запускать команду в этом блоке. Однако если это пространство имен существует в вашем кластере, вам нужно будет сообщить Cert-Manager, что оно не должно проходить валидацию, с помощью следующей команды:
kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=»true»
Компонент Webhook в Cert-Manager требует сертификаты TLS для безопасной связи с сервером API Kubernetes. Чтобы Cert-Manager впервые сгенерировал для него сертификаты, должна быть отключена валидация ресурса в пространстве имен, в котором он развернут. В противном случае он застрянет в бесконечном цикле, не имея возможности связаться с API и создать сертификаты TLS.
Вывод будет выглядеть так:
Затем нужно добавить в Helm репозиторий Jetstack, в котором находится чарт Cert-Manager. Для этого выполните следующую команду:
helm repo add jetstack https://charts.jetstack.io
Helm покажет следующий результат:
«jetstack» has been added to your repositories
Наконец, установите Cert-Manager в пространство имен cert-manager:
Вы увидите следующий вывод:
Вывод показывает, что установка прошла успешно. Как указано в NOTES в выводе, вам необходимо настроить Issuer для выдачи сертификатов TLS.
Теперь мы создадим Issuer, который выдает сертификаты Let’s Encrypt, и сохраним его конфигурацию в файле production_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
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-prod
# Enable the HTTP-01 challenge provider
http01: <>
Эта конфигурация определяет ClusterIssuer, который связывается с Let’s Encrypt для получения сертификатов. Вам нужно заменить your_email_address адресом электронной почты, чтобы получать срочные уведомления о безопасности и истечении срока действия ваших сертификатов.
Сохраните и закройте файл.
Запустите его с помощью kubectl:
Вы увидите следующий вывод:
Установив Cert-Manager, вы можете представить сертификаты ресурсу Ingress, определенному на предыдущем этапе. Откройте hello-kubernetes-ingress.yaml для редактирования:
Добавьте в него выделенные строки:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: hello-kubernetes-ingress
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
spec:
tls:
— hosts:
— hw1.example.com
— hw2.example.com
secretName: letsencrypt-prod
rules:
— host: hw1.example.com
http:
paths:
— backend:
serviceName: hello-kubernetes-first
servicePort: 80
— host: hw2.example.com
http:
paths:
— backend:
serviceName: hello-kubernetes-second
servicePort: 80
Блок tls в спецификации определяет, в каком секрете будут храниться сертификаты для сайтов (перечисленных в разделе hosts). Этот блок должен быть индивидуальным для каждого Ingress, который вы создаете.
Не забудьте заменить hw1.example.com и hw2.example.com собственными доменами. Когда вы закончите редактирование, сохраните и закройте файл.
Примените эту конфигурацию к вашему кластеру, выполнив следующую команду:
Вы увидите следующий вывод:
Вам нужно будет подождать несколько минут, чтобы серверы Let’s Encrypt выдали сертификаты для ваших доменов. В то же время вы можете отслеживать прогресс, проверив вывод следующей команды:
kubectl describe certificate letsencrypt-prod
Конец вывода будет выглядеть примерно так:
Если последняя строка выводит Certificate issued successfully, вы можете выйти, нажав CTRL + C. Перейдите к одному из ваших доменов в браузере и проверьте его работу. Вы увидите в браузере замочек слева от адресной строки, означающий, что ваше соединение защищено.
Вы установили Cert-Manager с помощью Helm и создали ClusterIssuer для Let’s Encrypt. После этого вы обновили свой ресурс Ingress, чтобы применить Issuer для создания сертификатов TLS. Также вы подтвердили, что HTTPS работает правильно, перейдя на один из ваших доменов в браузере.
