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

Вступление

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

В этом руководстве мы настроим поддерживаемые KubernetesNginx Ingress Controller и создадим некоторые ресурсы Ingress для маршрутизации трафика к нескольким фиктивным серверным службам. После настройки Ingress мы установимcert-manager в наш кластер для управления и предоставления сертификатов TLS для шифрования HTTP-трафика на Ingress.

Предпосылки

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

Кластер Kubernetes 1.10+ с включеннымrole-based access control (RBAC)
Инструмент командной строкиkubectl, установленный на вашем локальном компьютере и настроенный для подключения к вашему кластеру. Вы можете узнать больше об установкеkubectlin the official documentation.
Имя домена и DNS A записи, которые вы можете указать на балансировщик нагрузки DigitalOcean, используемый Ingress. Если вы используете DigitalOcean для управления записями DNS своего домена, обратитесь кHow to Manage DNS Records, чтобы узнать, как создавать записи A.
Менеджер пакетов Helm, установленный на вашем локальном компьютере, и Tiller установлен в вашем кластере, как подробно описано вHow To Install Software on Kubernetes Clusters with the Helm Package Manager. Убедитесь, что вы используете Helm v2.12.1 или новее, иначе у вас могут возникнуть проблемы с установкой диаграммы Helt cert-manager. Чтобы проверить версию Helm, которую вы установили, запуститеhelm version на локальном компьютере.
Утилита командной строкиwget, установленная на вашем локальном компьютере. Вы можете установитьwget с помощью диспетчера пакетов, встроенного в вашу операционную систему.

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

[[step-1 -—- setting-up-dummy-backend-services]] == Шаг 1. Настройка фиктивных серверных служб

Прежде чем мы развернем Ingress Controller, мы сначала создадим и развернем две фиктивные эхо-службы, на которые будем направлять внешний трафик с использованием 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: echo1Label Selector. Мы указываем, что в Deployment должно быть 2 реплики Pod, и что Pods должны запускать контейнер с именемecho1, запускающий образhashicorp/http-echo. Мы передаем параметрtext и устанавливаем его равнымecho1, чтобы веб-серверhttp-echo возвращалecho1. Наконец, мы открываем порт5678 на контейнере Pod.

После того, как вы будете удовлетворены фиктивным манифестом Service and Deployment, сохраните и закройте файл.

Затем создайте ресурсы 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           80/TCP    60s

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

Теперь, когда служба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 Pod реплику. Мы гарантируем, что установили для параметраtext значениеecho2, чтобы веб-сервер возвращал текстecho2.

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

kubectl create -f echo2.yaml

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

Outputservice/echo2 created
deployment.apps/echo2 created

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

kubectl get svc

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

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

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

[[step-2 -—- setting-up-the-kubernetes-nginx-ingress-controller]] == Шаг 2 - Настройка входящего контроллера Kubernetes Nginx

На этом этапе мы развернемv0.24.1 из поддерживаемых KubernetesNginx Ingress Controller. Обратите внимание, что существуют контроллеры входа Nginxseveral; сообщество Kubernetes поддерживает тот, который используется в этом руководстве, а Nginx Inc. поддерживаетkubernetes-ingress. Инструкции в этом руководстве основаны на инструкциях официального Kubernetes Nginx Ingress ControllerInstallation Guide.

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

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

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

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

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

Здесь мы используемapply вместоcreate, чтобы в будущем мы могли постепенно изменятьapply в объектах Ingress Controller вместо их полной перезаписи. Чтобы узнать больше оapply, обратитесь кManaging Resources в официальной документации 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 Controller, созданных из манифестаmandatory.yaml.

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

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

[.note] #Note: По умолчанию служба Nginx Ingress LoadBalancer имеет дляservice.spec.externalTrafficPolicy значениеLocal, которое направляет весь трафик балансировщика нагрузки на узлы, на которых работают модули Nginx Ingress. Другие узлы намеренно не проходят проверки работоспособности балансировщика нагрузки, чтобы входящий трафик не направлялся на них. Политики внешнего трафика выходят за рамки этого руководства, но чтобы узнать больше, вы можете обратиться кA Deep Dive into Kubernetes External Traffic Policies иSource IP for Services with Type=LoadBalancer из официальных документов Kubernetes.
#

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

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

[[step-3 -—- created-the-ingress-resource]] == Шаг 3 - Создание Ingress-ресурса

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

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

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

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

nano echo_ingress.yaml

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

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-запроса указывает имя домена целевого сервера. Чтобы узнать больше о заголовках запросов хоста, обратитесь к Mozilla Developer Networkdefinition page. Запросы с хостом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 Load Balancer. Внешний IP-адрес балансировщика нагрузки - это внешний IP-адрес службыingress-nginx, который мы получили на предыдущем шаге. Если вы используете DigitalOcean для управления записями DNS своего домена, обратитесь кHow to Manage DNS Records, чтобы узнать, как создавать записи A.

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

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

curl echo1.example.com

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

Outputecho1

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

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

curl echo2.example.com

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

Outputecho2

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

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

[[step-4 -—- install-and-configuring-cert-manager]] == Шаг 4 - Установка и настройка Cert-Manager

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

[.note] #Note: Перед установкой cert-manager убедитесь, что вы используете Helm v2.12.1 или новее. Чтобы проверить версию Helm, которую вы установили, запуститеhelm version на локальном компьютере.
#

Прежде чем использовать Helm для установки cert-manager в наш кластер, нам нужно создать cert-managerCustom Resource Definitions (CRD). Создайте их, `применив` прямо из диспетчера сертификатовGitHub repository:

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 repository в Helm. Этот репозиторий содержит диспетчер сертификатовHelm chart.

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 Encrypt, который предоставляет бесплатные сертификаты TLS и предлагает как промежуточный сервер для тестирования конфигурации вашего сертификата, так и рабочий сервер для развертывания проверяемых сертификатов TLS.

Давайте создадим тестового эмитента, чтобы убедиться, что механизм предоставления сертификатов работает правильно. Откройте файл с именем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.

Затем мы указываем адрес электронной почты для регистрации сертификата и создаем KubernetesSecret с именемletsencrypt-staging для хранения закрытого ключа учетной записи ACME. Мы также включаем механизм запросаHTTP-01. Чтобы узнать больше об этих параметрах, обратитесь к официальной документации Cert-Manager наIssuers.

Разверните ClusterIssuer, используяkubectl:

kubectl create -f staging_issuer.yaml

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

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

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

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

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-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, который определяет контроллер входа, который должен использоваться для реализации правил входа. Кроме того, мы определяем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 Encrypt.

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

[[step-5 -—- Rolling Out-Production-Issuer]] == Шаг 5 - Развертывание производственного эмитента

На этом этапе мы изменим процедуру, используемую для предоставления промежуточных сертификатов, и создадим действительный, проверяемый производственный сертификат для наших узлов 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.

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

Теперь разверните этого эмитента, используяkubectl:

kubectl create -f prod_issuer.yaml

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

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

Обновитеecho_ingress.yaml, чтобы использовать этого нового эмитента:

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 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
308 Permanent Redirect

308 Permanent Redirect
nginx/1.15.9

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

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

curl https://echo1.example.com

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

Outputecho1

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

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

Заключение

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

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

TOC

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

Вступление

Предпосылки

308 Permanent Redirect

Заключение

Related