Como o Kubernetes resolveu os problemas do meu time

Alguns meses atrás, meu time teve um problema. Nós precisávamos fazer nosso ambiente adaptativo a mudanças porque paramos de usar mais IP fixos e não nos agradava limitar um serviço a um node específico do cluster. Então começamos a usar o Kubernetes para atingir esse objetivo. E foram esses recursos que nos ajudaram:

Kube DNS: Kubernetes possibilita um serviço a acessar o outro apenas pelo nome, tirando a necessidade de controle de porta ou IP onde o outro serviço está. Além de ter um Load Balancing Interno que tira a necessidade de controlar em qual porta o serviço vai subir.

Load Balancing Interno: O Load Balancing Interno permite aos seus serviços escalar sem a necessidade de configurar um load balance ou controlar a porta em que cada serviço sobe e ter conexões não coesas.

Ingress: Kubernetes Ingress é o recurso que permite expor seu serviço para a rede externa. É  possível usar porta, hostname ou path para rotear seu serviço. Existem várias maneiras de se configurar um recurso de Ingress e vários provedores desse recurso. Nós usamos NGINX como  Daemon Set para ter o serviço de Ingress disponível nas portas 80 e 443. Então, qualquer conexão em qualquer node do cluster será então redirecionado para o serviço apropriado.

Self Healing: Self healing é o recurso que permite ao Kubernetes checar o estado de um serviço e ao detectar algum problema reiniciar o mesmo. Usamos esse recurso para resolver um problema onde alguns serviços não conseguiam se recuperar após perderem a conexão com o banco de dados. Expomos um recurso em nosso serviço que checa a conexão e ao não conseguir conectar retorna erro e o Kubernetes automaticamente reinicia e restaura o serviço.

Secrets: Secrets é o modo seguro de configurar e trafegar suas credenciais entre os serviços que compõem o cluster. Não vou ir fundo nesse tópico mas se você quiser uma solução mais robusta procure o Vault.

Como configuramos o Ingress de um serviço

Quando queremos expor um serviço no kubernetes, configuramos um ingress para ele. Exemplo:

Vamos dizer que temos os seguintes dois domínios:

kubernetes1.cedrotech.com.br

kubernetes2.cedrotech.com.br

Na versão anterior, cada um desses domínios era apontado para um node diferente do cluster e haviam regras que garantiam que o serviço iria subir naquele determinado node. Para manter o padrão, vamos configurar o ingress para rotear pelo hostname e encaminhar a requisição para o serviço adequado. A configuração será assim:

apiVersion:extensions/v1beta1

kind:Ingress

metadata:

 name:name-virtual-host-ingress

spec:

 rules:

 –host:kubernetes1.cedrotech.com.br

   http:

     paths:

     –backend:

         serviceName:service1

         servicePort:80

 –host:kubernetes2.cedrotech.com.br

   http:

     paths:

     –backend:

         serviceName:service2

         servicePort:80

E o fluxo ficará assim:

E foi desta maneira que tornamos nosso ambiente resiliente usando Kubernetes. Claro que havia outras formas porém o Kubernetes oferece recursos que torna isso muito mais fácil e simples o que nos ajudou muito e nos permitiu criar essa arquitetura robusta.