Pesquisa de site

Como configurar uma entrada Nginx com o Cert-Manager no Kubernetes

Introdução

Os Ingresses do Kubernetes permitem rotear de forma flexível o tráfego de fora do cluster do Kubernetes para os serviços dentro do cluster. Isso é feito usando os Recursos do Ingress, que definem regras para rotear o tráfego HTTP e HTTPS para os Serviços do Kubernetes, e os Controladores do Ingress, que implementam as regras balanceando a carga do tráfego e roteando-o para os serviços de back-end apropriados.

Os controladores Ingress populares incluem Traefik. As entradas fornecem uma alternativa mais eficiente e flexível para configurar vários serviços LoadBalancer, cada um dos quais usa seu próprio Load Balancer dedicado.

Neste guia, configuraremos o How To Set Up an Nginx Ingress on DigitalOcean Kubernetes usando o Helm, mantido pelo Kubernetes.

Pré-requisitos

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

  • Um cluster do Kubernetes 1.15+ com outro método.
  • A ferramenta de linha de comando kubectl instalada em sua máquina local e configurada para se conectar ao seu cluster. Você pode ler mais sobre a instalação do kubectl How to Connect to a DigitalOcean Kubernetes Cluster para saber como se conectar ao seu cluster usando kubectl.
  • Um nome de domínio e registros DNS A que você pode apontar para o balanceador de carga da DigitalOcean usado pelo Ingress. Se você estiver usando a DigitalOcean para gerenciar os registros DNS do seu domínio, consulte Como gerenciar registros DNS para saber como criar registros A.
  • O utilitário de linha de comando wget instalado em sua máquina local. Você pode instalar wget usando o gerenciador de pacotes embutido em seu sistema operacional.

Depois de configurar esses componentes, você está pronto para começar com este guia.

Etapa 1 — Configurando serviços de back-end fictícios

Antes de implantar o Ingress Controller, primeiro criaremos e distribuiremos dois serviços fictícios de eco para os quais rotearemos o tráfego externo usando o Ingress. Os serviços echo executarão os serviços dos documentos oficiais do Kubernetes.

Em sua máquina local, crie e edite um arquivo chamado echo1.yaml usando nano ou seu editor favorito:

  1. nano echo1.yaml

Cole o seguinte manifesto de serviço e implantação:

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 roteia o tráfego para os pods com o seletor de rótulos app: echo1. Ele aceita tráfego TCP na porta 80 e o roteia para a porta 5678, a porta padrão de http-echo.

Em seguida, definimos um Deployment, também chamado de echo1, que gerencia os Pods com o app: echo1 Label Selector. 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 o parâmetro text e o configuramos como echo1, para que o servidor web http-echo retorne echo1 . Por fim, abrimos a porta 5678 no contêiner do pod.

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

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

  1. kubectl apply -f echo1.yaml

Você deve ver a seguinte saída:

Output
service/echo1 created
deployment.apps/echo1 created

Verifique se o serviço foi iniciado corretamente confirmando que ele possui um ClusterIP, o IP interno no qual o serviço está exposto:

  1. kubectl get svc echo1

Você deve ver a seguinte saída:

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 echo1 agora está disponível internamente em 10.245.222.129 na porta 80. Ele encaminhará o tráfego para containerPort 5678 nos pods que selecionar.

Agora que o serviço echo1 está funcionando, repita este 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 essencialmente o mesmo manifesto de serviço e implantação acima, mas nomeamos e renomeamos o serviço e a implantação echo2. Além disso, para fornecer alguma variedade, criamos apenas 1 réplica de pod. Garantimos que definimos o parâmetro text como echo2 para que o servidor web retorne o texto echo2.

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

  1. kubectl apply -f echo2.yaml

Você deve ver a seguinte saída:

Output
service/echo2 created
deployment.apps/echo2 created

Mais uma vez, verifique se o serviço está funcionando:

  1. kubectl get svc

Você deve ver os serviços echo1 e 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 da Web fictícios de eco estão funcionando, podemos prosseguir com a implantação do Nginx Ingress Controller.

Etapa 2 — Configurando o Kubernetes Nginx Ingress Controller

Nesta etapa, implementaremos a v1.1.1 do Guia de instalação mantido pelo Kubernetes.

O Nginx Ingress Controller consiste em um pod que executa o servidor da Web Nginx e observa o plano de controle do Kubernetes em busca de objetos Ingress Resource novos e atualizados. Um Ingress Resource é essencialmente uma lista de regras de roteamento de tráfego para serviços de back-end. Por exemplo, uma regra de entrada pode especificar que o tráfego HTTP que chega no caminho /web1 deve ser direcionado para o servidor da web de back-end web1. Usando os recursos do Ingress, você também pode realizar roteamento baseado em host: por exemplo, roteamento de solicitações que atingem web1.your_domain.com para o serviço Kubernetes de back-end web1.

Nesse caso, como estamos implantando o Ingress Controller em um cluster Kubernetes da DigitalOcean, o Controller criará um LoadBalancer Service que provisiona um Load Balancer da DigitalOcean para o qual todo o tráfego externo será direcionado. Esse balanceador de carga roteará o tráfego externo para o pod do controlador Ingress executando o Nginx, que encaminhará o tráfego para os serviços de back-end apropriados.

Começaremos criando os recursos do Kubernetes do Nginx Ingress Controller. Eles consistem em ConfigMaps contendo a configuração do controlador, funções de controle de acesso baseado em função (RBAC) para conceder ao controlador acesso à API do Kubernetes e a implantação real do controlador de ingresso que usa v1.1.1 da imagem do Nginx Ingress Controller. Para ver uma lista completa desses recursos necessários, consulte o manifesto do repositório GitHub do Kubernetes Nginx Ingress Controller.

Observação: neste tutorial, estamos seguindo as instruções de instalação oficiais do provedor DigitalOcean. Você deve escolher o arquivo de manifesto apropriado dependendo do seu provedor Kubernetes.

Para criar os recursos, use kubectl apply e o sinalizador -f para especificar o arquivo de manifesto hospedado no GitHub:

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

Usamos apply aqui para que, no futuro, possamos aplicar de forma incremental as alterações aos objetos Ingress Controller em vez de sobrescrevê-los completamente. Para saber mais sobre aplicar, consulte Gerenciando recursos nos documentos oficiais do Kubernetes.

Você deve ver a seguinte saída:

Output
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
configmap/ingress-nginx-controller created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
service/ingress-nginx-controller-admission created
service/ingress-nginx-controller created
deployment.apps/ingress-nginx-controller created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
serviceaccount/ingress-nginx-admission created

Essa saída também serve como um resumo conveniente de todos os objetos Ingress Controller criados a partir do manifesto deploy.yaml.

Confirme se os pods do controlador Ingress foram iniciados:

  1. kubectl get pods -n ingress-nginx \

  2.   -l app.kubernetes.io/name=ingress-nginx --watch



Output
NAME                                       READY   STATUS      RESTARTS   AGE
ingress-nginx-admission-create-l2jhk       0/1     Completed   0          13m
ingress-nginx-admission-patch-hsrzf        0/1     Completed   0          13m
ingress-nginx-controller-c96557986-m47rq   1/1     Running     0          13m

Pressione CTRL+C para retornar ao seu prompt.

Agora, confirme se o balanceador de carga da DigitalOcean foi criado com sucesso, obtendo os detalhes do serviço com kubectl:

  1. kubectl get svc --namespace=ingress-nginx

Após alguns minutos, você deverá ver um endereço IP externo, correspondente ao endereço IP do balanceador de carga da DigitalOcean:

Output
NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.245.201.120   203.0.113.0   80:31818/TCP,443:31146/TCP   14m
ingress-nginx-controller-admission   ClusterIP      10.245.239.119   <none>            443/TCP                      14m

Anote o endereço IP externo do balanceador de carga, pois você precisará dele em uma etapa posterior.

Observação: por padrão, o serviço Nginx Ingress LoadBalancer tem service.spec.externalTrafficPolicy definido como o valor Local, que roteia todo o tráfego do balanceador de carga para nós que executam pods Nginx Ingress. Os outros nós falharão deliberadamente nas verificações de integridade do balanceador de carga para que o tráfego do Ingress não seja roteado para eles. As políticas de tráfego externo estão além do escopo deste tutorial, mas para saber mais, você pode consultar IP de origem para serviços com Type=LoadBalancer nos documentos oficiais do Kubernetes.

Esse balanceador de carga recebe tráfego nas portas HTTP e HTTPS 80 e 443 e o encaminha para o Ingress Controller Pod. O Ingress Controller irá então rotear o tráfego para o serviço de back-end apropriado.

Agora podemos apontar nossos registros DNS para esse balanceador de carga externo e criar alguns recursos de ingresso para implementar regras de roteamento de tráfego.

Etapa 3 — Criando o Recurso Ingress

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

Neste guia, usaremos o domínio de teste example.com. Você deve substituí-lo pelo nome de domínio que possui.

Primeiro, criaremos uma regra simples para rotear o tráfego direcionado para echo1.example.com para o serviço de back-end echo1 e o tráfego direcionado para echo2.example.com< /mark> para o serviço de back-end echo2.

Comece abrindo um arquivo chamado echo_ingress.yaml em seu editor favorito:

  1. nano echo_ingress.yaml

Cole a seguinte definição de entrada:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
spec:
  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

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

Aqui, especificamos que gostaríamos de criar um Ingress Resource chamado echo-ingress e rotear o tráfego com base no cabeçalho Host. Um cabeçalho de host de solicitação HTTP especifica o nome de domínio do servidor de destino. Para saber mais sobre cabeçalhos de solicitação de host, consulte o Mozilla Developer Network example.com será direcionado para o back-end echo2.

Agora você pode criar o Ingress usando kubectl:

  1. kubectl apply -f echo_ingress.yaml

Você verá a seguinte saída confirmando a criação do Ingress:

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

Para testar o Ingress, navegue até seu serviço de gerenciamento de DNS e crie registros A para echo1.example.com e echo2.example.com apontando para o IP externo do DigitalOcean Load Balancer. O IP externo do balanceador de carga é o endereço IP externo para o serviço ingress-nginx, que buscamos na etapa anterior. Se você estiver usando a DigitalOcean para gerenciar os registros DNS do seu domínio, consulte Como gerenciar registros DNS para saber como criar registros A.

Depois de criar os registros DNS echo1.example.com e echo2.example.com necessários, você pode testar o Ingress Controller e o recurso que criou usando curl utilitário de linha de comando.

Em sua máquina local, curl o serviço echo1:

  1. curl echo1.example.com

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

Output
echo1

Isso confirma que sua solicitação para echo1.example.com está sendo roteada corretamente por meio da entrada Nginx para o serviço de back-end echo1.

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

  1. curl echo2.example.com

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

Output
echo2

Isso confirma que sua solicitação para echo2.example.com está sendo roteada corretamente por meio da entrada Nginx para o serviço de back-end echo2.

Neste ponto, você configurou com sucesso um Nginx Ingress mínimo para executar o roteamento baseado em host virtual. Na próxima etapa, instalaremos o cert-manager para provisionar certificados TLS para nosso Ingress e habilitar o protocolo HTTPS mais seguro.

Etapa 4 — Instalando e configurando o Cert-Manager

Nesta etapa, instalaremos a v1.7.1 do cert-manager em nosso cluster. cert-manager é um complemento do Kubernetes que provisiona certificados TLS de Emissores.

Instale o cert-manager e suas instruções de instalação. Observe que um namespace chamado cert-manager será criado no qual os objetos cert-manager serão criados:

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

Você deve ver a seguinte saída:

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 cert-manager para pods em execução:

  1. kubectl get pods --namespace cert-manager



Output
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-578cd6d964-hr5v2              1/1     Running   0          99s
cert-manager-cainjector-5ffff9dd7c-f46gf   1/1     Running   0          100s
cert-manager-webhook-556b9d7dfd-wd5l6      1/1     Running   0          99s

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

Antes de começarmos a emitir certificados para nossos domínios echo1.example.com e echo2.example.com, precisamos criar um Emissor, que especifica a autoridade de certificação da qual x509 assinado certificados podem ser obtidos. Neste guia, usaremos a autoridade de certificação Let's Encrypt, que fornece certificados TLS gratuitos e oferece um servidor de teste para testar sua configuração de certificado e um servidor de produção para distribuir certificados TLS verificáveis.

Vamos criar um ClusterIssuer de teste para garantir que o mecanismo de provisionamento de certificados esteja funcionando corretamente. Um ClusterIssuer não tem escopo de namespace e pode ser usado por recursos de certificado em qualquer namespace.

Abra um arquivo chamado staging_issuer.yaml em seu editor de texto favorito:

nano staging_issuer.yaml

Cole o seguinte manifesto ClusterIssuer:

apiVersion: cert-manager.io/v1
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 gostaríamos de criar um ClusterIssuer chamado letsencrypt-staging e usar o servidor de teste Let's Encrypt. Posteriormente, usaremos o servidor de produção para distribuir nossos certificados, mas o servidor de produção limita as solicitações feitas contra ele, portanto, para fins de teste, você deve usar o URL de teste.

Em seguida, especificamos um endereço de e-mail para registrar o certificado e criamos um Kubernetes Issuers.

Distribua o ClusterIssuer usando kubectl:

  1. kubectl create -f staging_issuer.yaml

Você deve ver a seguinte saída:

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

Agora, repetiremos esse processo para criar o ClusterIssuer de produção. Observe que os certificados só serão criados após a anotação e atualização do recurso Ingress provisionado na etapa anterior.

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

nano prod_issuer.yaml

Cole o seguinte manifesto:

apiVersion: cert-manager.io/v1
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

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

Quando terminar de editar, salve e feche o arquivo.

Distribua este emissor usando kubectl:

  1. kubectl create -f prod_issuer.yaml

Você deve ver a seguinte saída:

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

Agora que criamos nossos ClusterIssuers de preparação e produção Let's Encrypt, estamos prontos para modificar o Ingress Resource que criamos acima e habilitar a criptografia TLS para echo1.example.com e echo2. example.com caminhos.

Se estiver usando Kubernetes da DigitalOcean, primeiro você precisa implementar a Etapa 6.

Etapa 5 — Habilitando a comunicação do pod por meio do balanceador de carga (opcional)

Antes de provisionar certificados do Let's Encrypt, o cert-manager primeiro executa uma autoverificação para garantir que o Let's Encrypt possa alcançar o Pod do cert-manager que valida seu domínio. Para que essa verificação passe no Kubernetes da DigitalOcean, você precisa habilitar a comunicação Pod-Pod por meio do balanceador de carga Nginx Ingress.

Para fazer isso, criaremos um registro DNS A que aponta para o IP externo do balanceador de carga da nuvem e anotaremos o manifesto Nginx Ingress Service com esse subdomínio.

Comece navegando até seu serviço de gerenciamento de DNS e crie um registro A para solução alternativa.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 para o serviço ingress-nginx, que buscamos na Etapa 2. Se você estiver usando a DigitalOcean para gerenciar os registros DNS do seu domínio, consulte Como gerenciar registros DNS para aprenda como criar registros A. Aqui, usamos o subdomínio solução alternativa, mas você pode usar qualquer subdomínio de sua preferência.

Agora que você criou um registro DNS apontando para o balanceador de carga do Ingress, anote o Ingress LoadBalancer Service com a anotação do-loadbalancer-hostname. Abra um arquivo chamado ingress_nginx_svc.yaml em seu editor favorito e cole o seguinte manifesto LoadBalancer:

apiVersion: v1
kind: Service
metadata:
  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-nginx
spec:
  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 manifesto de serviço foi extraído do arquivo de manifesto Nginx Ingress completo que você instalou na Etapa 2. Certifique-se de copiar o manifesto de serviço correspondente à versão do Nginx Ingress que você instalou; neste tutorial, é 1.1.1. Certifique-se também de definir a anotação do-loadbalancer-hostname para o domínio workaround.example.com.

Quando terminar, salve e feche o arquivo.

Modifique o serviço ingress-nginx-controller em execução usando kubectl apply:

kubectl apply -f ingress_nginx_svc.yaml

Você deve ver a seguinte saída:

Output
service/ingress-nginx-controller configured

Isso confirma que você anotou o serviço ingress-nginx-controller e os pods em seu cluster agora podem se comunicar uns com os outros usando este balanceador de carga ingress-nginx-controller.

Etapa 6 — Emitir certificados Let's Encrypt de teste e produção

Para emitir um certificado TLS de teste para nossos domínios, anotaremos echo_ingress.yaml com o ClusterIssuer criado na Etapa 4. Isso usará ingress-shim para criar e emitir automaticamente certificados para os domínios especificados no manifesto do Ingress.

Abra echo_ingress.yaml em seu editor favorito:

  1. nano echo_ingress.yaml

Adicione o seguinte ao manifesto do recurso Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  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

Aqui adicionamos uma anotação para definir o clusterIssuer do cert-manager como letsencrypt-staging, o certificado de teste ClusterIssuer criado na Etapa 4. Também adicionamos uma anotação que descreve o tipo de entrada, neste caso nginx.

Também adicionamos um bloco tls para especificar os hosts para os quais queremos adquirir certificados e especificamos um secretName. Esse segredo conterá a chave privada TLS e o certificado emitido. Certifique-se de trocar example.com pelo domínio para o qual você criou registros DNS.

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

Agora, enviaremos esta atualização para o objeto Ingress existente usando kubectl apply:

  1. kubectl apply -f echo_ingress.yaml

Você deve ver a seguinte saída:

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

Você pode usar kubectl describe para rastrear o estado das alterações do Ingress que acabou de aplicar:

  1. kubectl describe ingress



Output
Events:
  Type    Reason             Age               From                      Message
  ----    ------             ----              ----                      -------
  Normal  UPDATE             6s (x3 over 80m)  nginx-ingress-controller  Ingress default/echo-ingress
  Normal  CreateCertificate  6s                cert-manager              Successfully created Certificate "echo-tls"

Uma vez que o certificado foi criado com sucesso, você pode executar um describe nele para confirmar sua criação com sucesso:

  1. kubectl describe certificate

Você deve ver a seguinte saída na seção Events:

Output
Events:
  Type    Reason     Age    From          Message
  ----    ------     ----   ----          -------
  Normal  Requested  64s    cert-manager  Created new CertificateRequest resource "echo-tls-vscfw"
  Normal  Issuing    40s    cert-manager  The certificate has been successfully issued

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

Agora estamos prontos para enviar uma solicitação a um servidor echo de back-end para testar se o HTTPS está funcionando corretamente.

Execute o seguinte comando wget para enviar uma solicitação para echo1.example.com e imprimir os cabeçalhos de resposta para STDOUT:

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

Você deve ver a seguinte saída:

Output
. . .
HTTP request sent, awaiting response... 308 Permanent Redirect
. . .
ERROR: cannot verify echo1.example.com's certificate, issued by ‘ERROR: cannot verify echo1.example.com's certificate, issued by ‘CN=(STAGING) Artificial Apricot R3,O=(STAGING) Let's Encrypt,C=US’:
  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 ativado com sucesso, mas o certificado não pode ser verificado, pois é um certificado temporário falso emitido pelo servidor de teste Let's Encrypt.

Agora que testamos se tudo funciona usando esse certificado falso temporário, podemos distribuir certificados de produção para os dois hosts echo1.example.com e echo2.example.com . Para fazer isso, usaremos o letsencrypt-prod ClusterIssuer.

Atualize echo_ingress.yaml para usar letsencrypt-prod:

  1. nano echo_ingress.yaml

Faça a seguinte alteração no arquivo:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    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

Aqui, atualizamos o nome ClusterIssuer para letsencrypt-prod.

Quando estiver satisfeito com as alterações, salve e feche o arquivo.

Implemente as alterações usando kubectl apply:

  1. kubectl apply -f echo_ingress.yaml



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

Aguarde alguns minutos para que o servidor de produção Let's Encrypt emita o certificado. Você pode acompanhar seu progresso usando kubectl describe no objeto certificate:

  1. kubectl describe certificate echo-tls

Depois de ver a seguinte saída, o certificado foi emitido com sucesso:

Output
 Normal  Issuing    28s                 cert-manager  Issuing certificate as Secret was previously issued by ClusterIssuer.cert-manager.io/letsencrypt-staging
  Normal  Reused     28s                 cert-manager  Reusing private key stored in existing Secret resource "echo-tls"
  Normal  Requested  28s                 cert-manager  Created new CertificateRequest resource "echo-tls-49gmn"
  Normal  Issuing    2s (x2 over 4m52s)  cert-manager  The certificate has been successfully issued

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

  1. 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 as solicitações HTTP estão sendo redirecionadas para usar HTTPS.

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

  1. curl https://echo1.example.com

Agora você deve ver a seguinte saída:

Output
echo1

Você pode executar o comando anterior com o sinalizador -v detalhado para se aprofundar no handshake do certificado e verificar as informações do certificado.

Neste ponto, você configurou com sucesso o HTTPS usando um certificado Let's Encrypt para o seu Nginx Ingress.

Conclusão

Neste guia, você configura um Nginx Ingress para balancear a carga e rotear solicitações externas para serviços de back-end dentro de seu cluster Kubernetes. Você também protegeu o Ingress instalando o provedor de certificado cert-manager e configurando um certificado Let's Encrypt para dois caminhos de host.

Existem muitas alternativas para o Nginx Ingress Controller. Para saber mais, consulte os controladores do Ingress na documentação oficial do Kubernetes.

Para obter um guia sobre a implementação do Nginx Ingress Controller usando o gerenciador de pacotes Helm Kubernetes, consulte How To Set up an Nginx Ingress on DigitalOcean Kubernetes Using Helm.

Artigos relacionados: