Configurar o proxy de DNS

O proxy DNS é um recurso que oferece os seguintes recursos:

  1. Propagação de entradas DNS de Services em clusters em uma configuração de vários clusters.
  2. Preenchendo as entradas de DNS para ServiceEntry.

O Kubernetes fornece resolução de DNS apenas para Services no cluster local. Quando você precisa fornecer resolução de nomes para Services em clusters remotos ou usar um nome de host somente interno com ServiceEntry sem ter um servidor DNS somente interno adicional, o proxy DNS oferece uma maneira de resolver nomes DNS para esses casos.

Como configurar o proxy DNS

Para configurar o proxy DNS, configure a flag ISTIO_META_DNS_CAPTURE da seguinte maneira. É possível escolher a configuração do cluster ou por proxy.

Configuração em todo o cluster

Para configurar o proxy DNS no cluster, adicione metadados de proxy ISTIO_META_DNS_CAPTURE ao ConfigMap para MeshConfig. O nome do ConfigMap tem o formato istio-<revision_name>. Para mais detalhes sobre a revisão, consulte a visão geral da revisão.

apiVersion: v1
data:
  mesh: |-
    ...
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"        
    ...
kind: ConfigMap
metadata:
  name: istio-<revision_name>
  namespace: istio-system

Configuração por proxy

Para configurar o proxy DNS, adicione a anotação de metadados do proxy ISTIO_META_DNS_CAPTURE da seguinte maneira:

kind: Deployment
metadata:
  name: app1
  namespace: ns1
spec:
...
  template:
    metadata:
      annotations:
        proxy.istio.io/config: |
          proxyMetadata:
            ISTIO_META_DNS_CAPTURE: "true"
...

Verificando

Para verificar se tudo está configurado corretamente, siga as etapas.

Resolução de nomes para Service em clusters

Depois da configuração de vários clusters, implante um Service em apenas um dos clusters para verificar a resolução de nomes entre clusters.

Quando você tem o exemplo Service ns1/svc1, é possível encontrar ClusterIP em Service.

$ kubectl get -n ns1 svc1
kind: Service
metadata:
  name: svc1
  namespace: ns1
spec:
...
  ClusterIP: 210.200.1.1
...

Em seguida, ao usar curl do cluster other para o Service, ele vai mostrar o ClusterIP da seguinte maneira.

curl -sS -v svc1.ns1.svc.cluster.local
*   Trying 210.200.1.1:80...

Resolução de nome para ServiceEntry

Adicione um ServiceEntry com um nome de host não registrado no seu DNS. Para verificar a resolução de nomes, o exemplo a seguir tem o endereço explícito 192.168.123.123.

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: test-service-entry
spec:
  addresses:
  - "192.168.123.123"
  hosts:
  - not-existing-hostname.internal
  ports:
  - name: http
    number: 80
    protocol: HTTP
EOF

Em seguida, tente a resolução de DNS em um pod em que o proxy DNS está ativado. Por exemplo, se você executar um curl no pod, o endereço IP vai aparecer assim:

curl -sS -v not-existing-hostname.internal
*   Trying 192.168.123.123:80...

Alocação automática de IP para ServiceEntry

Ao usar ServiceEntry com o proxy DNS, é possível ativar a alocação automática de IP. Quando ativados, os endereços IP internos (do intervalo 240.240.0.0/16) são alocados automaticamente para hosts ServiceEntry que não especificam endereços IP explícitos em spec.addresses.

Como ativar a alocação automática de IP

Para ativar a alocação automática de IP, siga as instruções da sua implementação do plano de controle:

TRAFFIC_DIRECTOR

Para a implementação do plano de controle TRAFFIC_DIRECTOR, configure a alocação automática de IP no asm-options ConfigMap no namespace istio-system definindo ip_auto_allocation: "true".

O exemplo a seguir mostra um asm-options ConfigMap com a alocação automática de IP ativada:

apiVersion: v1
kind: ConfigMap
metadata:
  name: asm-options
  namespace: istio-system
data:
  # Enable IP auto-allocation for ServiceEntry (Rapid channel)
  ip_auto_allocation: "true"

Também é possível aplicar essa configuração usando kubectl patch:

kubectl patch configmap/asm-options -n istio-system --type merge \
  -p '{"data":{"ip_auto_allocation":"true"}}'

ISTIOD

Para clusters que usam a implementação do plano de controle ISTIOD (no cluster ou ISTIOD gerenciado), configure a alocação automática de IP adicionando ISTIO_META_DNS_AUTO_ALLOCATE: "true" aos metadados do proxy em MeshConfig:

apiVersion: v1
data:
  mesh: |-
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: "true"
        ISTIO_META_DNS_AUTO_ALLOCATE: "true"
kind: ConfigMap
metadata:
  name: istio-<revision_name>
  namespace: istio-system

Como verificar a alocação automática de IP

Para verificar se a alocação automática de IP funciona, siga estas etapas.

Antes da verificação, crie um ServiceEntry sem especificar spec.addresses:

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: auto-allocated-service-entry
  namespace: ns1
spec:
  hosts:
  - auto-allocated.internal
  ports:
  - name: http
    number: 80
    protocol: HTTP
  resolution: DNS
EOF

1. Verificar o endereço alocado em status.addresses (somente TRAFFIC_DIRECTOR)

Na implementação do TRAFFIC_DIRECTOR, o controlador aloca um VIP e preenche o campo status.addresses do ServiceEntry:

$ kubectl get serviceentry auto-allocated-service-entry -n ns1 -o yaml

A saída mostra o endereço alocado em status.addresses:

status:
  addresses:
  - host: auto-allocated.internal
    value: 240.240.0.1

2. Testar a resolução de DNS de um pod (TRAFFIC_DIRECTOR e ISTIOD)

Nas implementações TRAFFIC_DIRECTOR e ISTIOD, envie uma solicitação de um pod em que o proxy DNS esteja ativado para verificar se a resolução de nomes é resolvida para o VIP alocado:

$ kubectl exec deploy/curl -n ns1 -- curl -sS -v http://auto-allocated.internal

A tentativa de conexão deve ser resolvida para o VIP alocado automaticamente (por exemplo, 240.240.0.1:80):

*   Trying 240.240.0.1:80...