Introducción

Los Ingress de Kubernetes le permiten dirigir de manera flexible el tráfico del exterior de su clúster de Kubernetes a servicios dentro de su clúster. Esto se realiza usando recursos de Ingress, que definen reglas para dirigir el tráfico HTTP y HTTPS a servicios de Kubernetes, y controladores de Ingress, que implementan las reglas equilibrando la carga de tráfico y dirigiéndola a los servicios de backend correspondientes. Entre los controladores populares de Ingress se incluyen Nginx, Contour, HAProxy y Traefik. Los Ingress ofrecen una alternativa más eficiente y flexible para configurar varios servicios de LoadBalancer, cada uno de los cuales utiliza su propio equilibrador de cargas dedicado.

En esta guía, configuraremos el controlador de Ingress de Nginx mantenido por Kubernetes y crearemos algunos recursos de Ingress para dirigir el tráfico a varios servicios de backend ficticios. Una vez que configuremos el Ingress, instalaremos cert-manager en nuestro clúster para administrar y proporcionar certificados TLS, a fin de cifrar el tráfico de HTTP en el Ingress.

Requisitos previos

Antes de comenzar con esta guía, asegúrese de contar con lo siguiente:

  • Un clúster de Kubernetes 1.10, o una versión posterior, con control de acceso basado en roles (RBCA) activado
  • La herramienta de línea de comandos kubectl instalada en su equipo local y configurada para conectarse a su clúster. Puede leer más sobre la instalación de kubectl en la documentación oficial.
  • Un nombre de dominio y registros DNS A que puede orientar al equilibrador de cargas de DigitalOcean utilizado por el Ingress. Si usa DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para aprender a crear registros A.
  • El administrador de paquetes de Helm instalado en su computadora local y Tiller instalado en su clúster, como se detalla en Cómo instalar software en clústeres de Kubernetes con el administrador de paquetes de Helm. Asegúrese de utilizar Helm v2.12.1 o una versión posterior. De lo contrario, podría experimentar problemas al instalar el chart de Helm de cert-manager. Para comprobar la versión de Helm que instaló, ejecute helm version en su máquina local.
  • La utilidad de línea de comandos wget instalada en su equipo local. Puede instalar wget usando el administrador de paquetes incorporado en su sistema operativo.

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

Paso 1: Configurar servicios de backend ficticios

Antes de implementar el controlador de Ingress, crearemos e implementaremos primero dos servicios echo ficticios a los que dirigiremos el tráfico externo usando el Ingress. Los servicios echo ejecutan el contenedor del servidor web hashicorp/http-echo, el cual muestra una página que contiene una cadena de texto transmitida 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 equipo local, cree y edite un archivo llamado echo1.yaml usando nano o su editor favorito:

  • nano echo1.yaml

Pegue el siguiente manifiesto de servicio e implementación:

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

En este archivo, definimos un servicio llamado echo1 que dirige el tráfico hacia los Pods con el selector de etiquetas app: echo1. Acepta el tráfico de TCP en el puerto 80 y lo dirige al puerto 5678, el predeterminado de http-echo.

A continuación, definimos una implementación, también llamada echo1, que administra los Pods con el selector de etiquetas app: echo1. Especificamos que la implementación debe tener 2 réplicas de Pods y que los Pods deben iniciar un contenedor llamado echo1 ejecutando la imagen hashicorp/http-echo. Especificamos el parámetro text y lo fijamos en echo1, para que el servidor web http-echo muestre echo1. Por último, abrimos el puerto 5678 en el contenedor de Pods.

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

A continuación, cree los recursos de Kubernetes usando kubectl create con el indicador -f y especificando el archivo que acaba de guardar como un parámetro:

  • kubectl create -f echo1.yaml

Debería ver el siguiente resultado:

Output
service/echo1 created deployment.apps/echo1 created

Verifique que el servicio se haya iniciado de manera correcta confirmando que este tenga un ClusterIP, el IP interno en el que se expone el servicio:

  • kubectl get svc echo1

Debería ver el siguiente resultado:

Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE echo1 ClusterIP 10.245.222.129 <none> 80/TCP 60s

Esto indica que el servicio echo1 ahora se encuentra disponible de manera interna en 10.245.222.129 en el puerto 80. Reenviará el tráfico al containerPort 5678 en los Pods que seleccione.

Ahora que el servicio echo1 está activo y en ejecución, repita este proceso para el servicio echo2.

Cree y abra un archivo llamado 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

Aquí, básicamente utilizamos el mismo manifiesto de servicio e implementación de arriba, pero asignamos el nombre y la nueva etiqueta echo2 al servicio y a la implementación. Además, para proporcionar variedad, creamos solo una réplica de Pod. Nos aseguramos de fijar el parámetro de text en echo2 para que el servidor web muestre el texto echo2.

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

  • kubectl create -f echo2.yaml

Debería ver el siguiente resultado:

Output
service/echo2 created deployment.apps/echo2 created

Una vez más, compruebe que el servicio esté activo y en ejecución:

  • kubectl get svc

Debería ver ambos servicios echo1 y echo2 con ClusterIP asignados:

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

Ahora que nuestros servicios web ficticios de echo están activos y en ejecución, podemos implementar el controlador de Ingress de Nginx.

Paso 2: Configurar el controlador de Ingress de Nginx en Kubernetes

En este paso, implementaremos v0.24.1 del controlador de Ingress de Nginx mantenido por Kubernetes. Tenga en cuenta que hay varios controladores de Ingress de Nginx; la comunidad de Kubernetes mantiene el que utilizamos en esta guía y Nginx Inc. mantiene kubernetes-ingress. Las instrucciones de este tutorial están basadas en las de la Guía de instalación oficial del controlador de Ingress de Nginx en Kubernetes.

El controlador de Ingress de Nginx consta de un Pod que ejecuta el servidor web de Nginx y verifica el panel de control de Kubernetes en busca de objetos de recursos de Ingress nuevos y actualizados. Un recurso de Ingress es esencialmente una lista de reglas de enrutamiento de tráfico para los servicios de backend. Por ejemplo, una regla de Ingress puede especificar que el tráfico HTTP que llegue a la ruta /web1 deberá dirigirse hacía el servidor web de backend web1. Utilizando los recursos de Ingress, también puede aplicar enrutamiento basado en host: por ejemplo, dirigir las solicitudes que llegan de web1.yoyour_domain.com al servicio de backend de Kubernetes web1.

En este caso, debido a que implementamos el controlador de Ingress en un clúster de Kubernetes de DigitalOcean, el controlador creará un servicio LoadBalancer que hará aparecer un equilibrador de carga de DigitalOcean al cual se dirigirá todo el tráfico externo. Este equilibrador de carga dirigirá el tráfico externo al Pod del controlador de Ingress ejecutando Nginx, que posteriormente reenviará el tráfico a los servicios de backend correspondientes.

Comenzaremos creando primero los recursos de Kubernetes requeridos por el controlador de Ingress de Nginx. Estos consisten en ConfigMaps que contienen la configuración del controlador, roles de control de acceso basado en roles (RBAC) para otorgar al controlador acceso a la API de Kubernetes y la implementación real del controlador Ingress que utiliza v0.24.1 de la imagen del controlador de Ingress de Nginx. Para ver una lista completa de estos recursos necesarios, consulte el manifiesto del repositorio GitHub del controlador de Ingress de Nginx en Kubernetes.

Para crear estos recursos obligatorios, utilice kubectl apply y el indicador -f para especificar el archivo de manifiesto alojado en GitHub:

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

En este caso, utilizamos apply en lugar de create para que en el futuro podamos implementar cambios apply en incrementos a los objetos del controlador de Ingress en lugar de sobrescribirlos por completo. Para obtener más información sobre apply, consulte Recursos de administración de los documentos oficiales de Kubernetes.

Debería ver el siguiente resultado:

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.extensions/nginx-ingress-controller created

Este resultado también sirve como un resumen práctico de todos los objetos del controlador de Ingress creados a partir del manifiesto mandatory.yaml.

A continuación, crearemos el servicio LoadBalancer del controlador de Ingress, el cual creará un equilibrador de carga de DigitalOcean que equilibrará la carga y dirigirá el tráfico HTTP y HTTPS al Pod del controlador de Ingress implementado en el comando anterior.

Para crear el servicio LoadBalancer, una vez más utilice kubectl apply en un archivo de manifiesto que contenga la definición del servicio:

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

Debería ver el siguiente resultado:

Output
service/ingress-nginx created

Ahora, confirme que el equilibrador de carga de DigitalOcean se haya creado de manera exitosa obteniendo los detalles del servicio con kubectl:

  • kubectl get svc --namespace=ingress-nginx

Debería ver una dirección IP externa que corresponda a la dirección IP del equilibrador de carga de DigitalOcean:

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

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

Nota: Por defecto, para el servicio LoadBalancer de Ingress de Nginx se fijó service.spec.externalTrafficPolicy en el valor Local, que dirige todo el tráfico del equilibrador de carga a los nodos ejecutando los Pods de Ingress de Nginx. Los otros nodos experimentarán fallas de manera deliberada en las verificaciones de estado del equilibrador de carga, de modo que el tráfico de Ingress no se dirija a estos. Las políticas de tráfico externo están fuera del alcance de este tutorial, pero para obtener más información puede consultar Análisis detallado de las políticas de tráfico externo de Kubernetes e IP de origen para servicios con Type=LoadBalancer en los documentos oficiales de Kubernetes.

Este equilibrador de carga recibe tráfico en los puertos HTTP y HTTPS 80 y 443, y lo reenvía al Pod del controlador de Ingress. Luego, el controlador de Ingress dirigirá el tráfico al servicio de backend correspondiente.

Ahora podemos apuntar nuestros registros DNS hacia este equilibrador de carga externo y crear algunos recursos de Ingress para implementar reglas de enrutamiento de tráfico.

Paso 3: Crear el recurso de Ingress

Comencemos creando un recurso de Ingress mínimo para direccionar el tráfico orientado a un subdominio determinado hacia un servicio de backend correspondiente.

En esta guía, utilizaremos el dominio de prueba example.com. Deberá sustituirlo por el nombre de dominio que posea.

Primero crearemos una regla sencilla para direccionar el tráfico dirigido a echo1.example.com hacia el servicio de backend echo1 y el tráfico dirigido a echo2.example.com hacia el servicio de backend echo2.

Empiece abriendo un archivo llamado echo_ingress.yaml en su editor de texto favorito:

  • nano echo_ingress.yaml

Pegue la siguiente definición de ingress:

echo_ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  rules:
  - host: echo1.example.com
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.example.com
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

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

Aquí, especificamos que queremos crear un recurso de Ingress llamado echo-ingress y dirigir el tráfico según el encabezado del host. Una solicitud de encabezado de host HTTP especifica el nombre de dominio del servidor de destino. Para obtener más información sobre encabezados de solicitudes de hosts, consulte la página de definición de Mozilla Developer Network. Las solicitudes con el host echo1.example.com se dirigirán al backend echo1, configurado en el paso 1, y las solicitudes con el host echo2.example.com se dirigirán al backend echo2.

Ahora puede crear el Ingress usando kubectl:

  • kubectl apply -f echo_ingress.yaml

Visualizará la siguiente salida que confirma la creación de Ingress:

Output
ingress.extensions/echo-ingress created

Para comprobar el Ingress, diríjase a su servicio de administración de DNS y cree registros A para echo1.example.com y echo2.example.com apuntando al IP externo del equilibrador de carga de DigitalOcean. El IP externo del equilibrador de carga es la dirección IP externa para el servicio de ingress-nginx, que obtuvimos en el paso anterior. Si usa DigitalOcean para administrar los registros DNS de su dominio, consulte Cómo administrar registros DNS para aprender a crear registros A.

Una vez que haya creado los registros DNS echo1.example.com y echo2.example.com necesarios, puede probar el controlador y el recurso de Ingress que creó usando la utilidad de línea de comandos curl.

Desde su computadora local, aplique curl al servicio echo1.

  • curl echo1.example.com

Debe obtener la siguiente respuesta del servicio echo1:

Output
echo1

Esto confirma que su solicitud a echo1.example.com se está dirigiendo de manera correcta a través del Ingress de Nginx al servicio de backend echo1.

Ahora, realice la misma prueba para el servicio echo2:

  • curl echo2.example.com

Debe obtener la siguiente respuesta del servicio echo2:

Output
echo2

Esto confirma que su solicitud a echo2.example.com se está dirigiendo de manera correcta a través del Ingress de Nginx al servicio de backend echo2.

En este punto, habrá configurado con éxito un Ingress básico de Nginx para realizar enrutamientos virtuales basados en host. En el siguiente paso, instalaremos cert-manager usando Helm para proporcionar certificados TLS para nuestro Ingress y habilitaremos el protocolo HTTPS por ser más seguro.

Paso 4: Instalar y configurar Cert-Manager

En este paso, usaremos Helm para instalar cert-manager en nuestro clúster. cert-manager es un servicio de Kubernetes que proporciona certificados TLS de Let´s Encrypt, y otras autoridades certificadoras, y administra sus ciclos de vida. Los certificados pueden solicitarse y configurarse aplicando a recursos de Ingress la anotación certmanager.k8s.io/issuer, añadiendo una sección tls a la especificación de Ingress y configurando uno o más *emisores *para especificar su autoridad de certificación preferida. Para obtener más información sobre los objetos de emisores, consulte la documentación oficial de cert-manager sobre emisores.

Nota: Verifique que está utilizando Helm v2.12.1 o una versión posterior antes de instalar cert-manager. Para comprobar la versión de Helm que instaló, ejecute helm version en su equipo local.

Antes de usar Helm para instalar cert-manager en nuestro clúster, debemos crear las Definiciones de recursos personalizados (CRD) de cert-manager. Créelos con apply de manera directa desde el repositorio de cert-manager de GitHub:

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

Debería ver el siguiente resultado:

Output
customresourcedefinition.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

A continuación, añadiremos una etiqueta al espacio de nombres kube-system, donde instalaremos cert-manager, para habilitar la validación avanzada de recursos mediante un webhook:

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

Ahora, añadiremos el repositorio de Jetstack de Helm a Helm. Este repositorio contiene el chart de Helm de cert-manager.

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

Por último, podemos instalar el chart en el espacio de nombres de kube-system:

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

Debería ver el siguiente resultado:

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

Esto indica que la instalación de cert-manager se realizó de manera correcta.

Antes de comenzar a emitir certificados para nuestros hosts de Ingress, debemos crear un emisor, el cual especifica la autoridad de certificación de la que se pueden obtener certificados firmados x509. En esta guía, usaremos la autoridad de certificación de Let´s Encrypt, que proporciona certificados TLS gratuitos y ofrece un servidor de ensayo para probar la configuración de sus certificados y un servidor de producción para implementar certificados de TLS verificables.

Crearemos un emisor de prueba para asegurarnos de que el mecanismo de suministro de certificados funcione de manera correcta. Abra un archivo llamado staging_issuer.yaml en su editor de texto favorito:

nano staging_issuer.yaml

Pegue el siguiente manifiesto de 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: {}

Aquí especificamos que deseamos crear un objeto de ClusterIssuer llamado letsencrypt-staging y usar el servidor de ensayo de Let´s Encrypt. Más adelante usaremos el servidor de producción para implementar nuestros certificados, pero el servidor de producción puede limitar las solicitudes que se hagan con el mismo. Por ello, para fines de prueba es mejor usar la URL de ensayo.

A continuación, especificaremos una dirección de correo electrónico para registrar el certificado y crearemos un Secreto de Kubernetes llamado letsencrypt-staging para almacenar la clave privada de la cuenta de ACME. También habilitaremos el mecanismo de comprobación HTTP-01. Para obtener más información sobre estos parámetros, consulte la documentación oficial de cert-manager sobre emisores.

Implemente el ClusterIssuer usando kubectl:

  • kubectl create -f staging_issuer.yaml

Debería ver el siguiente resultado:

Output
clusterissuer.certmanager.k8s.io/letsencrypt-staging created

Ahora que creamos nuestro emisor de ensayo de Let´s Encrypt, estamos listos para modificar el recurso de Ingress que creamos previamente y habilitar el cifrado TLS para las rutas de echo1.example.com y echo2.example.com.

Abra echo_ingress.yaml de nuevo en su editor favorito:

  • nano echo_ingress.yaml

Añada lo siguiente al manifiesto de recurso de Ingress:

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

Aquí agregamos algunas anotaciones para especificar la ingress.class, que determina el controlador de Ingress que debería utilizarse para implementar las reglas de Ingress. Además, definimos que el cluster-issuer es letsencrypt-staging, el emisor de certificados que acabamos de crear.

Por último, agregamos un bloque de tls a fin de especificar los hosts para los que queremos adquirir certificados y especificamos un secretName. Este secreto contendrá la clave privada TLS y el certificado emitido.

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

Ahora actualizaremos el recurso de Ingress existente usando kubectl apply:

  • kubectl apply -f echo_ingress.yaml

Debería ver el siguiente resultado:

Output
ingress.extensions/echo-ingress configured

Puede usar kubectl describe para rastrear el estado de los cambios de Ingress que acaba de aplicar:

  • kubectl describe ingress
Output
Events: 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"

Una vez que el certificado se haya creado con éxito, puede ejecutar un describe adicional sobre este para confirmar aún más que se creó de forma correcta:

  • kubectl describe certificate

Debería ver el siguiente resultado en la sección Events:

Output
Events: 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

Esto confirma que el certificado TLS se realizó de forma correcta y que el cifrado HTTPS ahora está activo para los dos dominios configurados.

Ahora estamos listos para enviar una solicitud a un servidor de backend echo y probar que HTTPS funciona bien.

Ejecute el siguiente comando wget para enviar una solicitud a echo1.example.com e imprimir los encabezados de respuesta en STDOUT:

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

Debería ver el siguiente resultado:

Output
URL 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'.

Esto indica que HTTPS se habilitó con éxito, pero el certificado no puede verificarse porque es un certificado temporal de carácter falso emitido por el servidor de ensayo de Let´s Encrypt.

Ahora que probamos que todo funciona usando este certificado temporal falso, podemos implementar certificados de producción para los dos hosts echo1.example.com y echo2.example.com.

Paso 5: Implementar el emisor de producción

En este paso, modificaremos el procedimiento utilizado para proporcionar certificados de ensayo, y generaremos un certificado de producción válido y verificable para nuestros hosts de Ingress.

Para comenzar, crearemos primero un certificado de producción ClusterIssuer.

Abra un archivo llamado prod_issuer.yaml en su editor favorito:

nano prod_issuer.yaml

Pegue el siguiente manifiesto:

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: {}

Observe la URL del servidor de ACME diferente y el nombre de clave secreta letsencrypt-prod.

Cuando finalice la edición, guarde y cierre el archivo.

Ahora, implemente este emisor usando kubectl:

  • kubectl create -f prod_issuer.yaml

Debería ver el siguiente resultado:

Output
clusterissuer.certmanager.k8s.io/letsencrypt-prod created

Actualice echo_ingress.yaml para usar este nuevo emisor:

  • nano echo_ingress.yaml

Realice los siguientes cambios al archivo:

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

Aquí actualizamos el nombre de ClusterIssuer y el nombre secreto a letsencrypt-prod.

Una vez que esté satisfecho con sus cambios, guarde y cierre el archivo.

Implemente los cambios usando kubectl apply:

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

Espere unos minutos para que el servidor de producción de Let´s Encrypt emita el certificado. Puede supervisar el progreso de la operación usando kubectl describe en el objeto certificate:

  • kubectl describe certificate letsencrypt-prod

El certificado se habrá emitido de forma correcta cuando visualice el siguiente resultado:

Output
Events: 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

Ahora, realizaremos una prueba usando curl para verificar que HTTPS funcione de forma correcta:

  • curl echo1.example.com

Debería ver lo siguiente:

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>

Esto indica que las solicitudes HTTP se redirigen para emplear HTTPS.

Ejecute curl en https://echo1.example.com:

  • curl https://echo1.example.com

Ahora, debería ver el siguiente resultado:

Output
echo1

Puede ejecutar el comando anterior con el indicador verbose -v para profundizar en el protocolo de enlace del certificado y para verificar la información del certificado.

En este punto, habrá configurado con éxito HTTPS usando un certificado de Let´s Encrypt para su Ingress de Nginx.

Conclusión

A través de esta guía, configuró un Ingress de Nginx para equilibrar las cargas y dirigir las solicitudes externas a los servicios de backend dentro de su clúster de Kubernetes. También protegió el Ingress instalando el proveedor de certificado cert-manager y configurando un certificado de Let´s Encrypt para dos rutas de host.

Existen muchas alternativas al controlador de Ingress de Nginx. Para obtener más información, consulte Controladores de Ingress en la documentación oficial de Kubernetes.

0 Comments

Creative Commons License