Table of Contents
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 the cloud provider 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
kubectlde linha de comando instalada em sua máquina local e configurada para se conectar ao seu cluster. Você pode ler mais sobre como instalar okubectlna documentação oficial.
- Um registro de nome de domínio e DNS A que você possa apontar para o load balancers usado pelo Ingress. Se estiver usando o the cloud provider 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
wgetinstalado em sua máquina local. Você pode instalar owgetutilizando 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:
[label 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.
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:
[secondary_label 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:
[secondary_label 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:
[label 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:
[secondary_label 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:
[secondary_label 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 the cloud provider, o controlador criará um serviço de LoadBalancer, que irá inicializar um balanceador de carga da the cloud provider 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:
[secondary_label 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 the cloud provider 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:
[secondary_label 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
[secondary_label 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 the cloud provider 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 the cloud provider:
[secondary_label 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:
[label echo_ingress.yaml]
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:
[secondary_label 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 the cloud provider. 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 the cloud provider 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:
[secondary_label 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:
[secondary_label 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:
[secondary_label 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
[secondary_label 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:
[label staging_issuer.yaml]
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:
[secondary_label 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:
[label echo_ingress.yaml]
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:
[secondary_label 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
[secondary_label 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:
[secondary_label 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:
[secondary_label 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:
[label prod_issuer.yaml]
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:
[secondary_label 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:
[label echo_ingress.yaml]
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
[secondary_label 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:
[secondary_label 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:
[secondary_label 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:
[secondary_label 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 the cloud provider usando o Helm.
