Cómo configurar Ingress Nginx con Cert-Manager en DigitalOcean Kubernetes

Introducción

Los ingresos de Kubernetes le permiten encaminar de manera flexible el tráfico desde fuera de su clúster de Kubernetes hacia los servicios dentro de su clúster. Esto se logra mediante recursos de ingreso, que definen reglas para encaminar el tráfico HTTP y HTTPS hacia los servicios de Kubernetes, y controladores de ingreso, que implementan las reglas al equilibrar la carga del tráfico y encaminarlo hacia los servicios de backend adecuados.

Los controladores de ingreso más populares incluyen Nginx, Contour, HAProxy y Traefik. Los ingresos brindan una alternativa más eficiente y flexible a la configuración de servicios Múltiples LoadBalancer, cada uno de los cuales utiliza su propio Load Balancer dedicado.

En esta guía, configuraremos el controlador de ingreso de Nginx mantenido por Kubernetes y crearemos algunos recursos de ingreso para encaminar el tráfico a varios servicios de backend ficticios. Una vez que hayamos configurado el ingreso, instalaremos cert-manager en nuestro clúster para administrar y aprovisionar certificados TLS para cifrar el tráfico HTTP al ingreso. Esta guía no utiliza el administrador de paquetes Helm. Para obtener una guía sobre cómo implementar el controlador de ingreso de Nginx con Helm, consulte Cómo configurar un ingreso de Nginx en DigitalOcean Kubernetes con Helm.

Si está buscando un servicio de alojamiento de Kubernetes administrado, consulte nuestro servicio de Kubernetes simple y administrado diseñado para el crecimiento.

Prerrequisitos

Antes de comenzar con esta guía, debe tener disponible lo siguiente:

• Un clúster de Kubernetes 1.15+ con control de acceso basado en roles (RBAC) habilitado. Esta configuración utilizará un clúster de Kubernetes de DigitalOcean, pero puede crear un clúster con otro método.
• La kubectlherramienta de línea de comandos instalada en su máquina local y configurada para conectarse a su clúster. Puede leer más sobre la instalación kubectlen la documentación oficial. Si está utilizando un clúster Kubernetes de DigitalOcean, consulte Cómo conectarse a un clúster Kubernetes de DigitalOcean para obtener información sobre cómo conectarse a su clúster mediante kubectl.
• Un nombre de dominio y registros DNS A que puede apuntar al balanceador de carga de DigitalOcean utilizado por Ingress. Si utiliza DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para obtener información sobre cómo crear Aregistros.
• La wgetutilidad de línea de comandos instalada en su equipo local. Puede instalarla wgetutilizando el administrador de paquetes integrado en su sistema operativo.

Una vez que tenga estos componentes configurados, estará listo para comenzar con esta guía.

Paso 1: Configuración de servicios backend ficticios

Antes de implementar el controlador de Ingress, primero crearemos e implementaremos dos servicios de eco ficticios a los que enrutaremos el tráfico externo mediante Ingress. Los servicios de eco ejecutarán el hashicorp/http-echocontenedor del servidor web, que devuelve una página que contiene una cadena de texto que se pasa cuando se inicia el servidor web. Para obtener más información sobre http-echo, consulte su repositorio de GitHub y, para obtener más información sobre los servicios de Kubernetes, consulte Servicios en los documentos oficiales de Kubernetes.

En su máquina local, cree y edite un archivo llamado echo1.yamlusando nanosu editor favorito:

nano echo1.yaml

Pegue el siguiente manifiesto de servicio e implementación:

echo1.yaml

apiVersion: v1kind: Servicemetadata:  name: echo1spec:  ports:  - port: 80    targetPort: 5678  selector:    app: echo1---apiVersion: apps/v1kind: Deploymentmetadata:  name: echo1spec:  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

En este archivo, definimos un servicio llamado echo1que enruta el tráfico a los pods con el app: echo1selector de etiquetas. Acepta el tráfico TCP en el puerto 80y lo ingresa al puerto 5678, http-echoel puerto predeterminado de.

Luego definimos un Deployment, también llamado echo1, que administra Pods con el app: echo1Label Selector. Especificamos que el Deployment debe tener 2 réplicas de Pod y que los Pods deben iniciar un contenedor llamado que echo1ejecuta la hashicorp/http-echoimagen. Pasamos el textparámetro y lo configuramos en echo1, para que el http-echoservidor web devuelva echo1. Finalmente, abrimos el puerto 5678en el contenedor de Pod.

Una vez que esté satisfecho con su manifiesto de servicio e implementación ficticio, guarde y cierre el archivo.

Luego, crea los recursos de Kubernetes usando kubectl applyla -fbandera, especificando el archivo que acabas de guardar como parámetro:

kubectl apply -f echo1.yaml

Deberías ver el siguiente resultado:

Outputservice/echo1 createddeployment.apps/echo1 created

Verifique que el Servicio se haya iniciado correctamente confirmando que tiene una ClusterIP, la IP interna en la que está expuesta el Servicio:

kubectl get svc echo1

Deberías ver el siguiente resultado:

OutputNAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGEecho1     ClusterIP   10.245.222.129   none        80/TCP    60s

Esto indica que el echo1servicio ahora está disponible internamente en 10.245.222.129el puerto 80. Reenviará el tráfico a contenedorPort 5678en los pods que seleccione.

Ahora que el echo1servicio está en funcionamiento, repita este proceso para el echo2servicio.

Crea y abre un archivo llamado echo2.yaml:

echo2.yaml

apiVersion: v1kind: Servicemetadata:  name: echo2spec:  ports:  - port: 80    targetPort: 5678  selector:    app: echo2---apiVersion: apps/v1kind: Deploymentmetadata:  name: echo2spec:  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

Aquí, básicamente, usamos el mismo manifiesto de Service and Deployment que el anterior, pero nombramos y reetiquetamos Service and Deployment echo2. Además, para brindar algo de variedad, creamos solo una réplica de Pod. Nos aseguramos de configurar el textparámetro echo2para que el servidor web devuelva el texto echo2.

Guarde y cierre el archivo y cree los recursos de Kubernetes usando kubectl:

kubectl apply -f echo2.yaml

Deberías ver el siguiente resultado:

Outputservice/echo2 createddeployment.apps/echo2 created

Una vez más, verifique que el Servicio esté en funcionamiento:

kubectl get svc

Deberías ver tanto los servicios echo1como echo2los servicios con ClusterIP asignados:

OutputNAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGEecho1        ClusterIP   10.245.222.129   none        80/TCP    6m6secho2        ClusterIP   10.245.128.224   none        80/TCP    6m3skubernetes   ClusterIP   10.245.0.1       none        443/TCP   4d21h

Ahora que nuestros servicios web de eco ficticios están en funcionamiento, podemos pasar a implementar el controlador de ingreso Nginx.

Paso 2: Configuración del controlador de ingreso Nginx de Kubernetes

En este paso, implementaremos v1.1.1el controlador de ingreso Nginx mantenido por Kubernetes. Tenga en cuenta que existen varios controladores de ingreso Nginx; la comunidad de Kubernetes mantiene el que se usa en esta guía y Nginx Inc. mantiene kubernetes-ingress. Las instrucciones de este tutorial se basan en las de la Guía de instalación oficial del controlador de ingreso Nginx de Kubernetes.

El controlador de ingreso de Nginx consta de un pod que ejecuta el servidor web de Nginx y vigila el plano de control de Kubernetes en busca de objetos de recursos de ingreso nuevos y actualizados. Un recurso de ingreso es, en esencia, una lista de reglas de enrutamiento de tráfico para los servicios de backend. Por ejemplo, una regla de ingreso puede especificar que el tráfico HTTP que llega a la ruta /web1debe dirigirse hacia el web1servidor web de backend. Con los recursos de ingreso, también puede realizar un enrutamiento basado en host: por ejemplo, enrutar solicitudes que llegan web1.your_domain.comal servicio de Kubernetes de backend web1.

En este caso, debido a que estamos implementando el controlador de Ingress en un clúster Kubernetes de DigitalOcean, el controlador creará un servicio LoadBalancer que aprovisionará un balanceador de carga de DigitalOcean al que se dirigirá todo el tráfico externo. Este balanceador de carga enrutará el tráfico externo al pod del controlador de Ingress que ejecuta Nginx, que luego reenvía el tráfico a los servicios de backend correspondientes.

Comenzaremos creando los recursos de Kubernetes del controlador de ingreso de Nginx. Estos consisten en ConfigMaps que contienen la configuración del controlador, los roles de control de acceso basados ​​en roles (RBAC) para otorgarle acceso al controlador a la API de Kubernetes y la implementación real del controlador de ingreso que utiliza v1.1.1la imagen del controlador de ingreso de Nginx. Para ver una lista completa de estos recursos necesarios, consulte el manifiesto del repositorio de GitHub del controlador de ingreso de Nginx de Kubernetes.

Nota: En este tutorial, seguimos las instrucciones de instalación oficiales del proveedor de DigitalOcean. Debes elegir el archivo de manifiesto adecuado según tu proveedor de Kubernetes.

Para crear los recursos, utilice kubectl applyy la -fbandera para especificar el archivo de manifiesto alojado en GitHub:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.1/deploy/static/provider/do/deploy.yaml

Usamos applyaquí para que en el futuro podamos realizar applycambios incrementales en los objetos del controlador de ingreso en lugar de escribirlos por completo. Para obtener más información sobre apply, consulte Administración de recursos en la documentación oficial de Kubernetes.

Deberías ver el siguiente resultado:

Outputnamespace/ingress-nginx createdserviceaccount/ingress-nginx createdconfigmap/ingress-nginx-controller createdclusterrole.rbac.authorization.k8s.io/ingress-nginx createdclusterrolebinding.rbac.authorization.k8s.io/ingress-nginx createdrole.rbac.authorization.k8s.io/ingress-nginx createdrolebinding.rbac.authorization.k8s.io/ingress-nginx createdservice/ingress-nginx-controller-admission createdservice/ingress-nginx-controller createddeployment.apps/ingress-nginx-controller createdvalidatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission createdclusterrole.rbac.authorization.k8s.io/ingress-nginx-admission createdclusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission createdjob.batch/ingress-nginx-admission-create createdjob.batch/ingress-nginx-admission-patch createdrole.rbac.authorization.k8s.io/ingress-nginx-admission createdrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission createdserviceaccount/ingress-nginx-admission created

Esta salida también sirve como un resumen conveniente de todos los objetos del controlador de ingreso creados a partir del deploy.yamlmanifiesto.

Confirme que los pods del controlador de ingreso se hayan iniciado:

kubectl get pods -n ingress-nginx 
  -l app.kubernetes.io/name=ingress-nginx --watch

OutputNAME                                       READY   STATUS      RESTARTS   AGEingress-nginx-admission-create-l2jhk       0/1     Completed   0          13mingress-nginx-admission-patch-hsrzf        0/1     Completed   0          13mingress-nginx-controller-c96557986-m47rq   1/1     Running     0          13m

Pulse CTRL+Cpara volver al mensaje.

Ahora, confirme que el balanceador de carga de DigitalOcean se creó correctamente obteniendo los detalles del servicio con kubectl:

kubectl get svc --namespace=ingress-nginx

Después de varios minutos, debería ver una dirección IP externa, correspondiente a la dirección IP del balanceador de carga de DigitalOcean:

OutputNAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGEingress-nginx-controller             LoadBalancer   10.245.201.120   203.0.113.0   80:31818/TCP,443:31146/TCP   14mingress-nginx-controller-admission   ClusterIP      10.245.239.119   none            443/TCP                      14m

Anote la dirección IP externa del balanceador de carga, ya que la necesitará en un paso posterior.

Nota: De forma predeterminada, el servicio Nginx Ingress LoadBalancer Service tiene service.spec.externalTrafficPolicyel valor Local, que enruta todo el tráfico del balanceador de carga a los nodos que ejecutan pods Nginx Ingress. Los demás nodos no pasarán deliberadamente las comprobaciones de estado del balanceador de carga para que el tráfico de Ingress no se enrute hacia ellos. Las políticas de tráfico externo están fuera del alcance de este tutorial, pero para obtener más información, puede consultar Un análisis profundo de las políticas de tráfico externo de Kubernetes y la dirección IP de origen para los servicios con Type=LoadBalancer en los documentos oficiales de Kubernetes.

Este balanceador de carga recibe tráfico en los puertos HTTP y HTTPS 80 y 443, y lo reenvía al módulo del controlador de Ingress. El controlador de Ingress luego enrutará el tráfico al servicio de backend correspondiente.

Ahora podemos apuntar nuestros registros DNS a este balanceador de carga externo y crear algunos recursos de ingreso para implementar reglas de enrutamiento de tráfico.

Paso 3: creación del recurso de ingreso

Comenzamos creando un recurso de ingreso mínimo para encaminar el tráfico dirigido a un subdominio determinado a un servicio de backend correspondiente.

En esta guía, utilizaremos el dominio de prueba example.com . Debes sustituirlo por el nombre de dominio que posees.

Primero crearemos una regla simple para encaminar el tráfico dirigido a echo1.ejemplo.comal echo1servicio backend y al tráfico dirigido a echo2.ejemplo.comal echo2servicio backend.

Comience abriendo un archivo llamado echo_ingress.yamlen su editor favorito:

nano echo_ingress.yaml

Pegue la siguiente definición de ingreso:

echo_ingress.yaml

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: echo-ingressspec:  rules:  - host: echo1.example.com    http:        paths:        - pathType: Prefix          path: "/"          backend:            service:              name: echo1              port:                number: 80  - host: echo2.example.com    http:        paths:        - pathType: Prefix          path: "/"          backend:            service:              name: echo2              port:                number: 80

Cuando haya terminado de editar sus reglas de Ingress, guarde y cierre el archivo.

Aquí, hemos especificado que nos gustaría crear un recurso de ingreso llamado echo-ingressy encaminar el tráfico en función del encabezado Host. Un encabezado Host de solicitud HTTP especifica el nombre de dominio del servidor de destino. Para obtener más información sobre los encabezados de solicitud Host, consulte la página de definición de Mozilla Developer Network. Solicitudes con host echo1.ejemplo.comSerá dirigido al echo1backend configurado en el Paso 1 ya las solicitudes con el host echo2.ejemplo.comSerá dirigido al echo2backend.

Ahora puedes crear el Ingress usando kubectl:

kubectl apply -f echo_ingress.yaml

Verá el siguiente resultado que confirma la creación de Ingress:

Outputingress.networking.k8s.io/echo-ingress created

Para probar el ingreso, navegue hasta su servicio de administración de DNS y cree registros A para la IP externa del balanceador de carga de DigitalOcean echo1.example.comy que apunten a ella. La IP externa del balanceador de carga es la dirección IP externa del servicio, que obtuvimos en el paso anterior. Si está utilizando DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para aprender a crear registros.echo2.example.comingress-nginxA

Una vez que haya creado los registros DNS necesarios echo1.example.com, echo2.example.compuede probar el controlador de ingreso y el recurso que ha creado utilizando la curlutilidad de línea de comandos.

Desde su máquina local, curlel echo1Servicio:

curl echo1.example.com

Debería recibir la siguiente respuesta del echo1servicio:

Outputecho1

Esto confirma que su solicitud echo1.example.comse está enrutando correctamente a través del ingreso de Nginx al echo1servicio backend.

Ahora, realice la misma prueba para el echo2Servicio:

curl echo2.example.com

Debería recibir la siguiente respuesta del echo2Servicio:

Outputecho2

Esto confirma que su solicitud echo2.example.comse está enrutando correctamente a través del ingreso de Nginx al echo2servicio backend.

En este punto, ha configurado correctamente un Ingress Nginx mínimo para realizar el enrutamiento basado en host virtual. En el siguiente paso, instalaremos cert-manager para proporcionar certificados TLS para nuestro Ingress y habilitar el protocolo HTTPS más seguro.

Paso 4: Instalación y configuración de Cert-Manager

En este paso, lo instalaremosversión 1.7.1de cert-manager en nuestro clúster. cert-manager es un complemento de Kubernetes que proporciona certificados TLS de Let's Encrypt y otras autoridades de certificación (CA) y administra sus ciclos de vida. Los certificados se pueden solicitar y configurar automáticamente anotando Recursos de Ingress, agregando una tlssección a la especificación de Ingress y configurando uno o más Emisores o ClusterIssuers para especificar su autoridad de certificación preferida. Para obtener más información sobre los objetos Emisor y ClusterIssuer, consulte la documentación oficial de cert-manager sobre Emisores.

Instale cert-manager y sus definiciones de recursos personalizados (CRD), como Issuers y ClusterIssuers, siguiendo las instrucciones de instalación oficiales. Tenga en cuenta que se creará un espacio de nombres llamado cert-manageren el que se crearán los objetos de cert-manager:

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

Deberías ver el siguiente resultado:

Outputcustomresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io createdcustomresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io createdcustomresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io createdcustomresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created. . .deployment.apps/cert-manager-webhook createdmutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook createdvalidatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

Para verificar nuestra instalación, verifique el cert-managerespacio de nombres para los pods en ejecución:

kubectl get pods --namespace cert-manager

OutputNAME                                       READY   STATUS    RESTARTS   AGEcert-manager-578cd6d964-hr5v2              1/1     Running   0          99scert-manager-cainjector-5ffff9dd7c-f46gf   1/1     Running   0          100scert-manager-webhook-556b9d7dfd-wd5l6      1/1     Running   0          99s

Esto indica que la instalación del administrador de certificados se realizó correctamente.

Antes de comenzar a emitir certificados para nuestros dominios echo1.example.comy echo2.example.com, debemos crear un emisor, que especifique la autoridad de certificación de la que se pueden obtener certificados x509 firmados. En esta guía, utilizaremos la autoridad de certificación Let's Encrypt, que proporciona certificados TLS gratuitos y ofrece un servidor de prueba para probar la configuración de su certificado y un servidor de producción para implementar certificados TLS verificables.

Creemos un ClusterIssuer de prueba para asegurarnos de que el mecanismo de aprovisionamiento de certificados funciona correctamente. Un ClusterIssuer no tiene un ámbito de espacio de nombres y puede ser utilizado por recursos de certificado en cualquier espacio de nombres.

Abra un archivo llamado staging_issuer.yamlen su editor de texto favorito:

nano staging_issuer.yaml

Pegue el siguiente manifiesto ClusterIssuer:

emisor_de_escenario.yaml

apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata: name: letsencrypt-staging namespace: cert-managerspec: 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

Aquí especificamos que nos gustaría crear un ClusterIssuer llamado letsencrypt-stagingy usar el servidor de prueba Let's Encrypt. Más adelante, usaremos el servidor de producción para implementar nuestros certificados, pero el servidor de producción limita la velocidad de las solicitudes que se realizan en él, por lo que, para fines de prueba, debe usar la URL de prueba.

Luego, especificamos una dirección de correo electrónico para registrar el certificado y creamos un secreto de Kubernetes llamado letsencrypt-stagingpara almacenar la clave privada de la cuenta ACME. También utilizamos el HTTP-01mecanismo de desafío. Para obtener más información sobre estos parámetros, consulte la documentación oficial de cert-manager en Emisores.

Implemente ClusterIssuer utilizando kubectl:

kubectl create -f staging_issuer.yaml

Deberías ver el siguiente resultado:

Outputclusterissuer.cert-manager.io/letsencrypt-staging created

Ahora repetiremos este proceso para crear el ClusterIssuer de producción. Tenga en cuenta que los certificados solo se crearán después de anotar y actualizar el recurso Ingress provisto en el paso anterior.

Abra un archivo llamado prod_issuer.yamlen su editor favorito:

nano prod_issuer.yaml

Pegue el siguiente manifiesto:

prod_emisor.yaml

apiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:  name: letsencrypt-prod  namespace: cert-managerspec:  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

Tenga en cuenta la URL del servidor ACME diferente y el letsencrypt-prodnombre de la clave secreta.

Cuando haya terminado de editar, guarde y cierre el archivo.

Implementar este emisor mediante kubectl:

kubectl create -f prod_issuer.yaml

Deberías ver el siguiente resultado:

Outputclusterissuer.cert-manager.io/letsencrypt-prod created

Ahora que hemos creado nuestros clústeres de producción y ensayo Let's Encrypt, estamos listos para modificar el recurso de ingreso que creamos anteriormente y habilitar el cifrado TLS para las rutas echo1.example.comy echo2.example.com.

Si usa DigitalOcean Kubernetes, primero debe implementar una solución alternativa para que los pods puedan comunicarse con otros pods mediante Ingress. Si no usa DigitalOcean Kubernetes, puede pasar directamente al paso 6.

Paso 5: Habilitar la comunicación del pod a través del balanceador de carga (opcional)

Antes de proporcionar certificados de Let's Encrypt, cert-manager primero realiza una comprobación automática para garantizar que Let's Encrypt pueda acceder al pod de cert-manager que valida su dominio. Para que esta comprobación se realice en DigitalOcean Kubernetes, debe habilitar la comunicación entre pods a través del balanceador de carga de Nginx Ingress.

Para ello, crearemos un registro DNS A que puntear a la IP externa del balanceador de carga en la nube y anotaremos el manifiesto del servicio de ingreso de Nginx con este subdominio.

Comience navegando hasta su servicio de administración de DNS y cree un registro A para workaround.example.comapuntar a la IP externa del balanceador de carga de DigitalOcean. La IP externa del balanceador de carga es la dirección IP externa del ingress-nginxservicio, que obtuvimos en el paso 2. Si está utilizando DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para aprender a crear registros A. Aquí usamos el subdominio, workaroundpero usted es libre de usar el subdominio que prefiera.

Ahora que ha creado un registro DNS que apunta al balanceador de carga de Ingress, anote el servicio LoadBalancer de Ingress con la do-loadbalancer-hostnameanotación. Abra un archivo con el nombre ingress_nginx_svc.yamlen su editor favorito y pegue el siguiente manifiesto LoadBalancer:

ingreso_nginx_svc.yaml

apiVersion: v1kind: Servicemetadata:  annotations:    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: 'true'    service.beta.kubernetes.io/do-loadbalancer-hostname: "workaround.example.com"  labels:    helm.sh/chart: ingress-nginx-4.0.6    app.kubernetes.io/name: ingress-nginx    app.kubernetes.io/instance: ingress-nginx    app.kubernetes.io/version: 1.1.1    app.kubernetes.io/managed-by: Helm    app.kubernetes.io/component: controller  name: ingress-nginx-controller  namespace: ingress-nginxspec:  type: LoadBalancer  externalTrafficPolicy: Local  ports:    - name: http      port: 80      protocol: TCP      targetPort: http    - name: https      port: 443      protocol: TCP      targetPort: https  selector:    app.kubernetes.io/name: ingress-nginx    app.kubernetes.io/instance: ingress-nginx    app.kubernetes.io/component: controller

Este manifiesto de servicio se extrajo del archivo de manifiesto completo de Nginx Ingress que instaló en el paso 2. Asegúrese de copiar el manifiesto de servicio correspondiente a la versión de Nginx Ingress que instaló; en este tutorial, es 1.1.1. Asegúrese también de configurar la do-loadbalancer-hostnameanotación en el workaround.example.comdominio.

Cuando haya terminado, guarde y cierre el archivo.

Modifique el ingress-nginx-controllerservicio en ejecución usando kubectl apply:

kubectl apply -f ingress_nginx_svc.yaml

Deberías ver el siguiente resultado:

Outputservice/ingress-nginx-controller configured

Esto confirma que ha anotado el ingress-nginx-controllerservicio y los pods en su clúster ahora pueden comunicarse entre sí mediante este ingress-nginx-controllerbalanceador de carga.

Paso 6: emisión de certificados Let's Encrypt de producción y ensayo

Para emitir un certificado TLS provisional para nuestros dominios, anotaremos echo_ingress.yamlcon el ClusterIssuer creado en el Paso 4. Esto se usará ingress-shimpara crear y emitir automáticamente certificados para los dominios especificados en el manifiesto de Ingress.

Ábrelo echo_ingress.yamlen tu editor favorito:

nano echo_ingress.yaml

Agregue lo siguiente al manifiesto de recursos de Ingress:

echo_ingress.yaml

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: echo-ingress  annotations:    cert-manager.io/cluster-issuer: "letsencrypt-staging"    kubernetes.io/ingress.class: "nginx"spec:  tls:  - hosts:    - echo1.example.com    - echo2.example.com    secretName: echo-tls  rules:    - host: echo1.example.com      http:        paths:          - pathType: Prefix            path: "/"            backend:              service:                name: echo1                port:                  number: 80    - host: echo2.example.com      http:        paths:          - pathType: Prefix            path: "/"            backend:              service:                name: echo2                port:                  number: 80

Aquí agregamos una anotación para establecer el ClusterIssuer del administrador de certificados en letsencrypt-staging, el certificado de prueba ClusterIssuer creado en el Paso 4. También agregamos una anotación que describe el tipo de ingreso, en este caso nginx.

También agregamos un tlsbloque para especificar los hosts para los que queremos adquirir certificados y especificamos un secretName. Este secreto contendrá la clave privada TLS y el certificado emitido. Asegúrese de intercambiarlo example.comcon el dominio para el que ha creado registros DNS.

Cuando haya terminado de realizar cambios, guarde y cierre el archivo.

Ahora enviaremos esta actualización al objeto Ingress existente usandokubectl a