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.

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 gerenciador de pacotes Helm instalado em sua máquina local e o Tiller instalados no seu cluster, como descrito no tópico Como instalar um software nos clusters do Kubernetes com o gerenciador de pacotes Helm. Certifique-se de que esteja usando o Helm v2.12.1 ou posterior, senão podem ocorrer problemas ao instalar o gráfico Helm cert-manager. Para verificar a versão do Helm que está instalada, execute a helm version em sua máquina local.
  • 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:

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

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.

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

  • kubectl create -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:

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 create -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.24.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 o acesso do controlador à API do Kubernetes, além da Implantação real do controlador Ingress que usa a versão v0.24.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.24.1/deploy/mandatory.yaml

Usamos o recurso apply em vez do create para que, no futuro, possamos usar cada vez mais usar o apply para modificar os 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.extensions/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.24.1/deploy/provider/cloud-generic.yaml

Você deve ver o seguinte resultado:

Output
service/ingress-nginx created

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

Você deve ver um endereço IP externo, correspondente 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.

Nota: por padrão, o serviço LoadBalancer do Ingress para Nginx tem o service.spec.externalTrafficPolicy ajustado para o valor Local, o qual faz o roteamento do tráfego do balancedor de carga para os nós que executam os Pods do Ingress para Nginx. Os outros nós irão fracassar nas inspeções de integridade do balanceador de carga - propositadamente, de modo aque o tráfego do Ingress não seja roteado para os nós. As políticas de tráfego externas estão além do âmbito deste tutorial, mas para saber mais a respeito, consulte Um aprofundamento nas políticas de tráfego externo do Kubernetes e IP de origem para serviços com o Type=LoadBalancer dos documentos oficiais do Kubernetes.

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:

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

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 para Nginx básico para executar o roteamento com base em host virtual. No próximo passo, vamos instalar o cert-manager usando o Helm para fornecer certificados TLS para nosso Ingress e habilitar o protocolo HTTPS mais seguro.

Passo 4 — Instalando e configurando o Cert-Manager

Neste passo, vamos usar o Helm para instalar o cert-manager no 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 junto das notas técnicas do certmanager.k8s.io/issuer, anexando-se uma seção de tls para as especificações do Ingress e configurando-se um ou mais Emissores para especificar a autoridade certificadora de sua preferência. Para aprender mais sobre os objetos do Emissor, consulte a documentação oficial do cert-manager sobre Emissores.

Nota: certifique-se de que esteja usando o Helm v2.12.1 ou posterior antes de instalar o cert-manager. Para verificar a versão do Helm que está instalada, execute a helm version em sua máquina local.

Antes de usar o Helm para instalar o cert-manager no nosso cluster, precisamos criar as Definições de recursos personalizadas (CRDs) do cert-manager. Crie-as aplicando-as diretamente do repositório do Github do cert-manager:

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

Você deve ver o seguinte 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

Em seguida, vamos adicionar um rótulo no namespace kube-system, onde vamos instalar o cert-manager a fim de habilitarmos a validação de recursos avançados usando um webhook:

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

Agora, vamos adicionar o repositório Jetstack Helm ao Helm. Esse repositório contém o gráfico Helm cert-manager.

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

Por fim, podemos instalar o gráfico no namespace kube-system:

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

Você deve ver o seguinte 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

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:

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

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.certmanager.k8s.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:

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

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.extensions/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 UPDATE 1m (x2 over 13m) nginx-ingress-controller Ingress default/echo-ingress Normal CreateCertificate 1m cert-manager Successfully created Certificate "letsencrypt-staging"

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 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

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

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:

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

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.certmanager.k8s.io/letsencrypt-prod created

Atualize o echo_ingress.yaml para usar este novo emissor:

  • nano echo_ingress.yaml

Faça as seguintes alterações no arquivo:

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

Aqui, atualizamos tanto o ClusterIssuer quanto o nome secreto para o 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.extensions/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 letsencrypt-prod

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

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

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.

0 Comments

Creative Commons License