Como configurar um Nginx Ingress com Cert-Manager no Kubernetes da plataforma DigitalOcean

Introdução

Os Ingresses do Kubernetes permitem o roteamento do tráfego externo ao cluster do seu Kubernetes de maneira flexível para os Serviços dentro de seu cluster. Essa condição é alcançada quando usamos os Recursos de Ingress - que definem as regras para rotear o tráfego do HTTP e HTTPS para os Serviços do Kubernetes e para os *Controladores *do Ingress, os quais implementam as regras fazendo o balanceamento da carga do tráfego e o seu roteamento para os serviços de backend apropriados. Nginx, Contour, HAProxy e o Traefik são controladores Ingress populares. Os Ingresses fornecem uma alternativa mais eficiente e flexível para configurar vários serviços de LoadBalancer, cada qual usando seu próprio Load Balancer dedicado.

Neste guia, vamos configurar o Controlador Ingress para Nginx - mantido pelo Kubernetes - e criaremos alguns Recursos de Ingress para rotear o tráfego para vários serviços de back-end fictício. Uma vez configurado o Ingress, vamos instalar o cert-manager no nosso cluster para gerenciar e fornecer certificados TLS para criptografar o tráfego de HTTP para o Ingress. Este guia não usa o gerenciador de pacotes Helm. Para obter um guia sobre como inplantar o Controlador do Nginx Ingres usando o Helm, consulte o artigo Como configurar um Nginx Ingress no Kubernetes da DigitalOcean usando o Helm.

Pré-requisitos

Antes de começar com este guia, você deve ter o seguinte disponível:

• Um cluster do Kubernetes 1.10+ com controle de acesso baseado em função (RBAC) habilitado
• A ferramenta kubectl de linha de comando instalada em sua máquina local e configurada para se conectar ao seu cluster. Você pode ler mais sobre como instalar o kubectl na documentação oficial.
• Um registro de nome de domínio e DNS A que você possa apontar para o DigitalOcean Load Balancer usado pelo Ingress. Se estiver usando o DigitalOcean para gerenciar os registros de DNS do seu domínio, consulte Como gerenciar os registros de DNS para aprender como criar um registro A.
• O utilitário de linha de comando wget instalado em sua máquina local. Você pode instalar o wget utilizando o gerenciador de pacotes integrado em seu sistema operacional.

Assim que tiver esses componentes configurados, você estará pronto para começar com este guia.

Passo 1 — Configurando os serviços de back-end fictício

Antes de implantar o Controlador Ingress, primeiro vamos criar e implantar dois serviços de eco fictício para os quais vamos rotear o tráfego externo usando o Ingress. Os serviços de eco irão executar o contêiner de servidor Web hashicorp/http-echo, os quais retornarão uma página com uma string de texto transmitida quando o servidor Web for iniciado. Para aprender mais sobre o http-echo, consulte seu GitHub Repo e, para aprender mais sobre os Kubernetes Services, consulte o tópico Serviços dos documentos oficiais do Kubernetes.

Na sua máquina local, crie e edite um arquivo chamado de eco1.yaml usando o nano ou seu editor favorito:

nano echo1.yaml

Cole no manifesto de Serviço e implantação a seguir:

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

Neste arquivo, definimos um serviço chamado echo1 que faz o roteamento do tráfego para os Pods com o seletor de rótulo app: echo1. Ele aceita o tráfego TCP na porta 80 e o roteia para a porta 5678 -a porta padrão do http-echo.

Em eguida, definimos uma Implantação, também chamada de echo1, a qual gerencia os Pods com o Seletor de rótulo app:echo1. Especificamos que a Implantação deve ter 2 réplicas de Pod e que os Pods devem iniciar um contêiner chamado echo1 executando a imagem hashicorp/http-echo. Passamos no parâmetro text e o configuramos para o echo1, para que o servidor Web http-echo retorne echo1. Por fim, abrimos a porta 5678 no contêiner do Pod.

Assim que estiver satisfeito com seu serviço fictício e o manifesto de implantação, salve e feche o arquivo.

Em seguida, crie os recursos do Kubernetes usando o kubectl apply com o sinalizador -f, especificando o arquivo que você acabou de salvar como um parâmetro:

kubectl apply -f echo1.yaml

Você deve ver o seguinte resultado:

Output
service/echo1 created
deployment.apps/echo1 created

Verifique se o serviço iniciou corretamente, confirmando que ele tem um ClusterIP, o IP interno no qual o serviço será exposto:

kubectl get svc echo1

Você deve ver o seguinte resultado:

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

Isso indica que o serviço de echo1 está disponível internamente em 10.245.222.129 na porta 80. Ele encaminhará o tráfego para a containerPort 5678 nos Pods que ele selecionar.

Agora que o serviço de echo1 está em execução, repita esse processo para o serviço echo2.

Crie e abra um arquivo chamado 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

Aqui, usamos basicamente o mesmo manifesto de Serviço e implantação acima, mas nomeamos e rotulamos novamente o Serviço e implantação echo2. Além disso, para darmos mais variedade, criaremos apenas 1 réplica do Pod. Nós garantimos que definimos o parâmetro text para o echo2 para que o servidor Web retorne o texto echo2.

Salve e feche o arquivo e crie os recursos do Kubernetes usando o kubectl:

kubectl apply -f echo2.yaml

Você deve ver o seguinte resultado:

Output
service/echo2 created
deployment.apps/echo2 created

Novamente, verifique se o serviço está em execução:

kubectl get svc

Você deve ver tanto o serviço echo1 como o serviço echo2 com ClusterIPs atribuídos:

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

Agora que nossos serviços de Web echo fictícios estão em execução, podemos seguir em frente para implantar o Controlador Ingress para o Nginx.

Passo 2 — Configurando o Controlador Ingress do Kubernetes para Nginx

Neste passo, vamos implantar a versão v0.26.1 do Controlador Ingress para Nginx mantido pelo Kubernetes. Note que existem vários Controladores Ingress para Nginx; a comunidade do Kubernetes mantém o controlador que iremos usar neste guia e a Nginx Inc. mantém o kubernetes-ingress. As instruções neste tutorial são baseadas controladores do Guia de instalação oficial para o Controlador Ingress da Kubernetes para Nginx.

O Controlador Ingress para Nginx consiste de um Pod que executa o servidor Web Nginx e monitora o plano de controle do Kubernetes em relação aos objetos novos e atualizados de Recursos de Ingress. Um recurso Ingress é, essencialmente, uma lista de regras de roteamento de tráfego para serviços de back-end. Por exemplo, uma regra de Ingress pode especificar que o tráfego HTTP chegando no caminho /web1 deve ser direcionado para o servidor Web de back-end web1. Ao usar os recursos de Ingress, é possível realizar o roteamento baseado em host: por exemplo, roteando os pedidos que chegarem para o web1.your_domain.com para o Serviço de back-end do Kubernetes web1.

Neste caso, devido a estarmos implantando o controlador Ingress para um cluster de Kubernetes da DigitalOcean, o controlador criará um serviço de LoadBalancer, que irá inicializar um balanceador de carga da DigitalOcean para o qual todo o tráfego externo será direcionado. Este balanceador de carga fará o roteamento do tráfego externo para o Pod do controlador Ingress que executa o Nginx, que, na sequência, encaminhará o tráfego para os serviços de back-end apropriados.

Vamos começar criando os recursos necessários do Kubernetes pelo Controlador Ingress para Nginx. Tais recursos incluem os ConfigMaps que contêm a configuração do Controlador, Funções de controle de acesso baseado em função (RBAC) para conceder ao controlador acesso à API do Kubernetes, além da Implantação real do controlador Ingress que usa a versão v0.26.1 da imagem do controlador Ingress para Nginx. Para ver uma lista completa dos recursos necessários, consulte o manifesto do repositório Github do Controlador Ingress para Nginx do Kubernetes.

Para criar esses recursos obrigatórios, utilize o kubectl apply e o sinalizador -f para especificar o arquivo do manifesto hospedado no GitHub:

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

Usamos o recurso apply aqui para que, no futuro, possamos usar cada vez as alterações do apply nos objetos do controlador Ingress, em vez de substituí-los completamente. Para aprender mais sobre o apply, consulte o tópico Gerenciando recursos dos documentos oficiais do Kubernetes.

Você deve ver o seguinte 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.apps/nginx-ingress-controller created

Este resultado também serve como um resumo conveniente de todos os objetos do controlador Ingress criados a partir do manifesto mandatory.yaml.

Em seguida, vamos criar o serviço LoadBalance do controlador Ingress, o qual criará um Load Balancer da Digital Ocean que irá balancear a carga e rotear o tráfego de HTTP e HTTPS para o Pod do Controlador Ingress implantado no comando anterior.

Para criar o serviço do LoadBalancer, mais uma vez, utilize o kubectl apply - um arquivo de manifesto que contém a definição do serviço:

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

Você deve ver o seguinte resultado:

Output
service/ingress-nginx created

Confirme se os Pods do Controlador Ingress iniciaram:

kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx

Output
NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE
ingress-nginx   nginx-ingress-controller-7fb85bc8bb-lnm6z   1/1     Running   0          2m42s

Agora, confirme que o Load Balancer da DigitalOcean foi criado com sucesso, buscando os detalhes do serviço com o kubectl:

kubectl get svc --namespace=ingress-nginx

Depois de vários minutos, você deverá ver um endereço IP externo, que corresponde ao endereço IP do Load Balancer da 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 o endereço de IP externo do Load Balancer, já que você precisará dele em um passo mais a frente.

Este balanceador de carga recebe o tráfego nas portas HTTP e HTTPS 80 e 443 e o encaminha para o pod do controlador Ingress. Na sequência, o controlador Ingress irá rotear o tráfego para o serviço de back-end apropriado.

Agora podemos apontar nossos registros de DNS neste Load Balancer externo e criar alguns recursos de Ingress para implementar regras de roteamento de tráfego.

Passo 3 — Criando o Recurso do Ingress

Vamos começar criando um recurso de Ingress mínimo para rotear o tráfego direcionado a um dado subdomínio para um serviço de back-end correspondente.

Neste guia, vamos usar o domínio teste example.com. Você deve substituí-lo por um nome de domínio seu.

Primeiramente, vamos criar uma regra simples para rotear o tráfego direcionado para **echo1.example.com **para o serviço de back-end do echo1 e o tráfego direcionado para o echo2.example.com para o serviço de back-end do echo2.

Inicie abrindo um arquivo chamado echo_ingress.yaml no seu editor favorito:

nano echo_ingress.yaml

Cole na seguinte definição de ingresso:

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

Quando terminar de editar suas regras do Ingress, salve e feche o arquivo.

Aqui, especificamos que gostaríamos de criar um resurso de Ingress chamado echo-ingress e rotear o tráfeco com base no cabeçalho do Host. O cabeçalho de Host com um pedido de HTTP especifica o nome de domínio do servidor de destino. Para aprender mais sobre os cabeçalhos de pedidos do Host, consulte a página de definições da Rede de Desenvolvedores da Mozilla (MDN). Os pedidos junto ao host echo1.example.com serão direcionados para o back-end echo1 - configurado no Passo 1 - e os pedidos junto ao host echo2.example.com serão direcionados para o back-end echo2.

Agora, você pode criar o Ingress usando o kubectl:

kubectl apply -f echo_ingress.yaml

Você verá o seguinte resultado confirmando a criação do Ingress:

Output
ingress.extensions/echo-ingress created

Para testar o Ingress, navegue até o seu serviço de gerenciamento DNS e crie registros A para o echo1.example.com e echo2.example.com apontando para o IP externo do balanceador de carga da DigitalOcean. O IP externo do balanceador de carga é o endereço IP externo do serviço ingress-nginx, que buscamos no passo anterior. Se estiver usando o DigitalOcean para gerenciar os registros de DNS do seu domínio, consulte Como gerenciar os registros de DNS para aprender como criar um registro A.

Assim que você tiver criado os registros DNS echo1.example.com e echo2.example.com necessários, você pode testar controlador e o recurso do Ingress que criou, utilizando o utilitário de linha de comando curl.

De sua máquina local, faça o curl do serviço echo1:

curl echo1.example.com

Você deve obter a seguinte resposta do serviço echo1:

Output
echo1

Isso confirma que seu pedido de echo1.example.com está sendo roteado corretamente através do Ingress para Nginx para o serviço de back-end echo1.

Agora, faça o mesmo teste com o serviço echo2:

curl echo2.example.com

Você deve obter a seguinte resposta do serviço echo2:

Output
echo2

Isso confirma que seu pedido para o echo2.example.com está sendo roteado corretamente através do Ingress para Nginx para o serviço de back-end echo2.

Neste ponto, você terá definido um Ingress báxico para Nginx para realizar o roteamento com base em host virtual. No próximo passo, vamos instalar o cert-manager para fornecer certificados TLS para o nosso Ingress e habilitar o protocolo HTTPS mais seguro.

Passo 4 — Instalando e configurando o Cert-Manager

Neste passo, vamos instalar o cert-manager em nosso cluster. O cert-manager é um serviço do Kubernetes que fornece certificados TLS do Let’s Encrypt e outras autoridades certificadoras e também gerencia seus ciclos de vida. Os certificados podem ser solicitados e configurados através de observações nos recursos do Ingress com a anotação cert-manager.io/issuer, anexando uma seção de tls para as especificações do Ingress e configurando um ou mais Issuers (Emissores) ou ClusterIssuers para especificar a autoridade certificadora de sua preferência. Para aprender mais sobre os objetos do Issuer e do Cluster, consulte a documentação oficial do cert-manager sobre Issuers.

Antes de instalarmos o cert-manager, primeiro vamos criar um Namespace no qual ele possa executar:

kubectl create namespace cert-manager

Na sequência, vamos instalar o cert-manager e suas Definições de Recursos Personalizados (CRD) como Issuers e ClusterIssuers. Faça isto,aplicando o manifesto diretamente do repositório GitHub do cert-manager:

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.12.0/cert-manager.yaml

Você deve ver o seguinte resultado:

Output
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificates.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
. . .
deployment.apps/cert-manager-webhook created
mutatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created
validatingwebhookconfiguration.admissionregistration.k8s.io/cert-manager-webhook created

Para verificar nossa instalação, verifique o Namespace do cert-manager em relação aos pods em execução:

kubectl get pods --namespace cert-manager

Output
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-5c47f46f57-jknnx              1/1     Running   0          27s
cert-manager-cainjector-6659d6844d-j8cbg   1/1     Running   0          27s
cert-manager-webhook-547567b88f-qks44      1/1     Running   0          27s

Isso indica que a instalação do cert-manager foi bem-sucedida.

Antes de começar a emitir certificados para nossos hosts do Ingress, precisamos criar um emissor, o qual especifica a autoridade certificadora da qual será possível obter os certificados x509 assinados. Neste guia, vamos usar a autoridade o certificado do Let’s Encrypt, que fornece certificados TLS gratuitos e também oferece um servidor de preparação para a realização dos testes da configuração do seu certificado e um servidor de produção para implantar certificados TLS verificáveis.

Vamos criar um emissor teste para garantir que o mecanismo de fornecimento do certificado esteja funcionando corretamente. Abra um arquivo chamado staging_issuer.yaml no seu editor de texto favorito:

nano staging_issuer.yaml

Cole no manifesto do ClusterIssuer a seguir:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
 name: letsencrypt-staging
 namespace: cert-manager
spec:
 acme:
   # The ACME server URL
   server: https://acme-staging-v02.api.letsencrypt.org/directory
   # Email address used for ACME registration
   email: your_email_address_here
   # Name of a secret used to store the ACME account private key
   privateKeySecretRef:
     name: letsencrypt-staging
   # Enable the HTTP-01 challenge provider
   solvers:
   - http01:
       ingress:
         class:  nginx

Aqui, especificamos que queremos criar um objeto de ClusterIssuer chamado de letsencrypt-staging e usar o servidor de preparação do Let’s Encrypt. Mais tarde, vamos usar o servidor de produção para implantar nossos certificados. Entretanto, poderá haver solicitações de limitação de taxa em relação ao servidor, de modo que é melhor usar o URL de preparação para os testes.

Depois, especificamos um endereço de e-mail para registrar o certificado e criamos um Kubernetes Secret chamado letsencrypt-staging para armazenar a chave privada da conta ACME. Também habilitamos o mecanismo de desafio do HTTP-01. Para aprender mais sobre esses parâmetros, consulte a documentação oficial do cert-manager sobre Emissores.

Implemente o ClusterIssuer usando o kubectl:

kubectl create -f staging_issuer.yaml

Você deve ver o seguinte resultado:

Output
clusterissuer.cert-manager.io/letsencrypt-staging created

Agora que criamos o nosso emissor preparatório do Let’s Encrypt, estamos prontos para modificar o recurso do Ingress que criamos acima e habilitar a criptografia TLS para os caminhos do echo1.example.com e do echo2.example.com.

Abra novamente o echo_ingress.yaml no seu editor favorito:

nano echo_ingress.yaml

Adicione o seguinte ao manifesto recurso do Ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
spec:
  tls:
  - hosts:
    - echo1.hjdo.net
    - echo2.hjdo.net
    secretName: echo-tls
  rules:
  - host: echo1.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Aqui, adicionamos algumas anotações para especificar a ingress.class, a qual determina o controlador do Ingress que deve ser usado para implementar as regras do Ingress. Além disso, definimos o cluster-issuer para ser o letsencrypt-staging, o emissor de certificados que acabamos de criar.

Por fim, adicionamos um bloco tls para especificar os hosts para os quais queremos adquirir certificados e especificar um secretName. Esse segredo irá conter a chave privada do TLS e o certificado emitido.

Quando terminar de fazer as alterações, salve e feche o arquivo.

Agora, vamos atualizar o recurso do Ingress existente usando o kubectl apply:

kubectl apply -f echo_ingress.yaml

Você deve ver o seguinte resultado:

Output
ingress.networking.k8s.io/echo-ingress configured

É possível usar o kubectl describe para rastrear o estado das alterações do Ingress que acabou de aplicar:

kubectl describe ingress

Output
Events:
  Type    Reason             Age               From                      Message
  ----    ------             ----              ----                      -------
  Normal  CREATE             14m               nginx-ingress-controller  Ingress default/echo-ingress
  Normal  CreateCertificate  67s   cert-manager              Successfully created Certificate "echo-tls"
  Normal  UPDATE             53s   nginx-ingress-controller  Ingress default/echo-ingress

Assim que o certificado tiver sido criado com sucesso, você poderá executar um describe adicional nele para confirmar que sua criação foi bem-sucedida:

kubectl describe certificate

Você deve ver o seguinte resultado na seção Events:

Output
Events:
  Type    Reason         Age   From          Message
  ----    ------         ----  ----          -------
  Normal  GeneratedKey  2m12s  cert-manager  Generated a new private key
  Normal  Requested     2m12s  cert-manager  Created new CertificateRequest resource "echo-tls-3768100355"
  Normal  Issued        47s    cert-manager  Certificate issued successfully

Isso confirma que o certificado TLS foi emitido com sucesso e a criptografia do HTTPS agora está ativa para os dois domínios configurados.

Agora, estamos prontos para enviar um pedido para um servidor echo de back-end para testar o funcionamento correto do HTTPS.

Execute o comando wget a seguir para enviar um pedido para o echo1.example.com e imprima os cabeçalhos de resposta para o STDOUT:

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

Você deve ver o seguinte resultado:

Output
. . .
HTTP request sent, awaiting response... 308 Permanent Redirect
. . .
ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=Fake LE Intermediate X1’:
  Unable to locally verify the issuer's authority.
To connect to echo1.example.com insecurely, use `--no-check-certificate'.

Isso indica que o HTTPS foi habilitado com sucesso, mas o certificado não pode ser verificado, já que ele é um certificado temporário falso emitido pelo servidor de preparação do Let’s Encrypt.

Agora que testamos que tudo funciona usando esse certificado falso temporário, podemos implantar os certificados de produção para os dois hosts, o echo1.example.com e o echo2.example.com.

Passo 5 — Implantando o emissor de produção.

Neste passo, vamos modificar o procedimento usado para fornecer os certificados de preparo e gerar um certificado de produção válido e verificável para os nossos hosts de Ingress.

Para começar, vamos primeiro criar um certificado de produção ClusterIssuer.

Abra um arquivo chamado prod_issuer.yaml no seu editor favorito:

nano prod_issuer.yaml

Cole no manifesto seguinte:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
  namespace: cert-manager
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: your_email_address_here
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx

Note o URL diferente do servidor ACME e o nome da chave secreta do letsencrypt-prod.

Quando terminar de editar, salve e feche o arquivo.

Agora, implante esse Emissor usando o kubectl:

kubectl create -f prod_issuer.yaml

Você deve ver o seguinte resultado:

Output
clusterissuer.cert-manager.io/letsencrypt-prod created

Atualize o echo_ingress.yaml para usar este novo emissor:

nano echo_ingress.yaml

Altere o arquivo da seguinte maneira:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - echo1.hjdo.net
    - echo2.hjdo.net
    secretName: echo-tls
  rules:
  - host: echo1.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.hjdo.net
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Aqui, atualizamos o nome do ClusterIssuer para letsencrypt-prod.

Assim que estiver satisfeito com suas alterações, salve e feche o arquivo.

Implemente as alterações usando o kubectl apply:

kubectl apply -f echo_ingress.yaml

Output
ingress.networking.k8s.io/echo-ingress configured

Espere alguns minutos para o servidor de produção do Let’s Encrypt emitir o certificado. Você pode rastrear o andamento do processo, usando a opção kubectl describe no objeto certificate:

kubectl describe certificate echo-tls

Assim que você ver o seguinte resultado, significa que o certificado foi emitido com sucesso:

Output
Events:
  Type    Reason        Age                  From          Message
  ----    ------        ----                 ----          -------
  Normal  GeneratedKey  8m10s                cert-manager  Generated a new private key
  Normal  Requested     8m10s                cert-manager  Created new CertificateRequest resource "echo-tls-3768100355"
  Normal  Requested     35s                  cert-manager  Created new CertificateRequest resource "echo-tls-4217844635"
  Normal  Issued        10s (x2 over 6m45s)  cert-manager  Certificate issued successfully

Agora, vamos realizar um teste usando o curl para verificar se o HTTPS está funcionando corretamente:

curl echo1.example.com

Você deve ver o seguinte:

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>

Isso indica que os pedidos do HTTP estão sendo redirecionados para usar o HTTPS.

Execute o curl em https://echo1.example.com:

curl https://echo1.example.com

Agora, você deve ver o seguinte resultado:

Output
echo1

É possível executar o comando anterior com o sinalizador detalhado -v para uma busca mais aprofundada no handshake do certificado e para verificar as informações do certificado.

Neste ponto, você já terá configurado o HTTPS com sucesso usando um certificado do Let’s Encrypt para o Ingress do seu Nginx.

Conclusão

Neste guia, você configurou um Ingress para Nginx para balancear carga e rotear pedidos externos para serviços de backend dentro do seu cluster do Kubernetes. Você também protegeu o Ingress, instalando o provedor de certificados cert-manager e configurando um certificado do Let’s Encrypt para dois caminhos de host.

Existem muitas alternativas para o controlador Ingress para Nginx. Para saber mais, consulte o tópico Controladores Ingress da documentação oficial do Kubernetes.

Para obter um guia sobre como implantar o Controlador para o Nginx Ingress usando o gerenciador de pacotes Helm para Kubernetes, consulte o artigo Como configurar um Nginx Ingress no Kubernetes da DigitalOcean usando o Helm.