Integrando o Ingress NGINX com o Sensedia Service Mesh

A instalação padrão do Sensedia Service Mesh utiliza o Istio Ingress Gateway para expor externamente os serviços presentes no cluster. Para utilizar outro ingress (no caso de já haver um outro instalado no cluster, por exemplo), configurações adicionais na instalação são necessárias para que todas as regras de segurança e controle de tráfego sejam respeitadas.

Esta página mostra como integrar o Ingress NGINX com a instalação do Sensedia Service Mesh.

Integrando o sidecar do Istio com o Ingress NGINX

Primeiramente, é necessário adicionar o sidecar do Istio aos pods do controller do Ingress NGINX, de modo que todas as requisições que partirem dele em direção aos serviços do cluster passem antes pelo sidecar do Istio, que por sua vez conhece e aplica as regras configuradas.

Para isso, adicione a label istio-injection: enabled ao namespace onde o Ingress NGINX estiver instalado, como no exemplo a seguir:

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    istio-injection: enabled

Além dessa label, a anotação sidecar.istio.io/inject: "true" também deve ser adicionada aos pods do controller do Ingress NGINX. Se você estiver utilizando o helm para a instalação/atualização, realize as seguintes alterações no arquivo helm-values.yaml:

controller:
  podAnnotations:
    sidecar.istio.io/inject: "true"
    traffic.sidecar.istio.io/includeInboundPorts: ""

  admissionWebhooks:
    patch:
      podAnnotations:
        sidecar.istio.io/inject: "false"

defaultBackend:
  podAnnotations:
    sidecar.istio.io/inject: "true"

Além da anotação que habilita a injeção do sidecar aos pods, a anotação traffic.sidecar.istio.io/includeInboundPorts: "" também é fundamental para o funcionamento. De forma padrão, o sidecar intercepta tanto as requisições de entrada como as de saída. Tal comportamento causaria um conflito com o container do Ingress NGINX. Essa anotação, portanto, desabilita o monitoramento do tráfego de entrada, se atendo apenas ao de saída.

Expondo um serviço externamente

Algumas modificações são necessárias nos objetos Ingress do Kubernetes para que os serviços sejam corretamente expostos via Ingress NGINX e integrados ao Sensedia Service Mesh. Abaixo segue um exemplo de objeto Ingress com as devidas configurações:

apiVersion:  networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-name
  namespace: ingress-namespace
  annotations:
    # Esta especificação garante que o nginx irá usar o IP do service para roteamento ou invés do IP dos pods
    nginx.ingress.kubernetes.io/service-upstream: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: "*.pod-info.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: pod-info
            port:
              number: 80

Como indicado no exemplo acima, a anotação nginx.ingress.kubernetes.io/service-upstream: "true" é necessária para indicar ao NGINX que, durante o encaminhamento das requisições, o IP que deve ser utilizado é o do serviço, não o do pod. Isso é necessário para trabalhar com estratégias de deploy avançado em que vários deployments de versões diferentes podem compartilhar um mesmo serviço, estando o Sensedia Service Mesh encarregado pelo gerenciamento do tráfego.

Uma vez aplicado o objeto Ingress, as últimas configurações devem ser realizadas diretamente na interface do Sensedia Service Mesh.

  1. Na tela de Edição do Mesh, adicione o(s) host(s) da aplicação, como no exemplo da figura abaixo. É possível inserir vários hosts separados por vírgula.

    Os hosts inseridos nesta etapa devem ser os mesmos configurados no objeto Ingress aplicado anteriormente.
    nginx hosts
    Cadastrando o(s) host(s) da aplicação
  2. Por fim, na tela de configuração do serviço desejado, crie uma regra de Traffic Routing do tipo "External".

    Ao configurar a regra, o campo Bind to default ingress deve ser desmarcado, indicando que o ingress a ser utilizado não é o padrão (Istio Ingress Gateway), mas sim o Ingress NGINX:

    nginx traffic routing
    Criando uma regra de Traffic Routing com o campo "Bind to default ingress" desabilitado
Thanks for your feedback!
EDIT
How useful was this article to you?