Está a ver a documentação da malha de serviço v1.22.

Versões disponíveis

Cloud Service Mesh
Arquivo 1.24
Arquivo 1.23
Arquivo 1.22
Arquivo 1.21
Arquivo 1.20
Arquivo 1.19
Arquivo 1.18

Esta página foi traduzida pela API Cloud Translation.

Peça registos de proxy

O Cloud Service Mesh suporta dois tipos diferentes de registos de acesso no Cloud Logging: registos de tráfego (também conhecidos como registos de acesso da Google Cloud Observability) e registos de acesso do Envoy. Esta página mostra como ativar, desativar, ver e interpretar estes registos. Tenha em atenção que os registos de tráfego estão ativados por predefinição.

Ativar e desativar registos de acesso

Managed Cloud Service Mesh

Registos de acesso do Envoy

Execute o seguinte comando para ativar os registos de acesso do Envoy e desativar os registos de tráfego:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-disable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
  - providers:
      - name: stackdriver
    disabled: true
EOF

Tenha em atenção que o nome do fornecedor do registo de tráfego é stackdriver.

Registos de tráfego

Por predefinição, os registos de tráfego estão ativados e os registos de acesso do Envoy estão desativados. Se ativou anteriormente os registos de acesso do Envoy e quer ativar os registos de tráfego e desativar os registos de acesso do Envoy, execute o seguinte comando:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-enable-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
EOF

Ambos

Para ativar os registos de acesso e os registos de tráfego do Envoy, execute o seguinte comando:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: enable-envoy-and-sd-access-log
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
      - name: stackdriver
EOF

Para desativar os registos de acesso do Envoy e os registos de tráfego, execute o seguinte comando:

cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: disable-envoy-and-sd
  namespace: istio-system
spec:
  accessLogging:
  - providers:
      - name: envoy
    disabled: true
  - providers:
      - name: stackdriver
    disabled: true
EOF

Gerido `istiod`

Registos de acesso do Envoy

Execute os seguintes comandos para ativar o registo de acesso do Envoy:

Execute o seguinte comando para adicionar accessLogFile: /dev/stdout:

cat <<EOF | kubectl apply -f -
apiVersion: v1
data:
  mesh: |-
    accessLogFile: /dev/stdout
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
EOF

em que release-channel é o seu canal de lançamento (asm-managed, asm-managed-stable ou asm-managed-rapid).

Execute o seguinte comando para ver o configmap:

 kubectl get configmap istio-release-channel -n istio-system -o yaml

Para verificar se o registo de acesso está ativado, certifique-se de que a linha accessLogFile: /dev/stdout aparece na secção mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Registos de tráfego

Os registos de tráfego estão ativados por predefinição.

No cluster

Registos de acesso do Envoy

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"

Para mais informações, consulte o artigo Ative o registo de acesso do Envoy.

Registos de tráfego

Os registos de tráfego estão ativados por predefinição, exceto se o Cloud Service Mesh estiver instalado no Google Distributed Cloud com a AC do Istio (anteriormente conhecido como Citadel).

Para ativar os registos de tráfego no Google Distributed Cloud com a CA do Istio quando instalar o Cloud Service Mesh no cluster, use a flag --option stackdriver. Em alternativa, pode ativar os registos de tráfego no Google Distributed Cloud com a AC do Istio depois de instalar o Cloud Service Mesh no cluster.

Visualizar registos de acesso

Registos de acesso do Envoy

Linha de comandos

Para ver os registos de acesso do Envoy no registo do istio-proxy, execute o seguinte comando:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Logs Explorer

Para ver os registos de acesso do Envoy no Explorador de registos:

Navegue para o Explorador de registos:

Aceda ao Explorador de registos
Selecione o Google Cloud projeto adequado.
Execute a seguinte consulta:

resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"

Registos de tráfego

Para ver os registos de tráfego no Explorador de registos:

Navegue para o Explorador de registos:

Aceda ao Explorador de registos
Selecione o Google Cloud projeto adequado.

Execute a seguinte consulta consoante esteja a ver os registos de acesso do cliente ou do servidor:

Registos do servidor

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"

Registos do cliente

resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"

Para ver os registos de tráfego na página Cloud Service Mesh de um serviço durante um intervalo de tempo especificado, siga estes passos:

Na Google Cloud consola, aceda à página Cloud Service Mesh.

Aceda à página Cloud Service Mesh
Em Serviços, selecione o nome do serviço que quer inspecionar.
Aceda à página Métricas.
Especifique um intervalo de tempo no menu pendente Intervalo de tempo ou defina um intervalo personalizado com a cronologia.
Em Selecione uma opção de filtro, clique em Ver registos de tráfego.

O registo de tráfego tem o nome server-accesslog-stackdriver e está anexado ao recurso monitorizado correspondente (k8s_container ou gce_instance) que o seu serviço está a usar. O registo de tráfego contém as seguintes informações:

Propriedades do pedido HTTP, como ID, URL, tamanho, latência e cabeçalhos comuns.
Informações da carga de trabalho de origem e destino, como o nome, o espaço de nomes, a identidade e as etiquetas comuns.
Se a monitorização estiver ativada, são apresentadas informações de rastreio, como a amostragem, o ID de rastreio e o ID de intervalo.

Uma entrada de registo de exemplo tem o seguinte aspeto:

{
  insertId: "1awb4hug5pos2qi"
  httpRequest: {
    requestMethod: "GET"
    requestUrl: "YOUR-INGRESS/productpage"
    requestSize: "952"
    status: 200
    responseSize: "5875"
    remoteIp: "10.8.0.44:0"
    serverIp: "10.56.4.25:9080"
    latency: "1.587232023s"
    protocol: "http"
  }
  resource: {
    type: "k8s_container"
    labels: {
      location: "us-central1-a"
      project_id: "YOUR-PROJECT"
      pod_name: "productpage-v1-76589d9fdc-ptnt9"
      cluster_name: "YOUR-CLUSTER-NAME"
      container_name: "productpage"
      namespace_name: "default"
    }
  }
  timestamp: "2020-04-28T19:55:21.056759Z"
  severity: "INFO"
  labels: {
    destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage"
    response_flag: "-"
    destination_service_host: "productpage.default.svc.cluster.local"
    source_app: "istio-ingressgateway"
    service_authentication_policy: "MUTUAL_TLS"
    source_name: "istio-ingressgateway-5ff85d8dd8-mwplb"
    mesh_uid: "YOUR-MESH-UID"
    request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632"
    destination_namespace: "default"
    source_principal:  "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"
    destination_workload: "productpage-v1"
    destination_version: "v1"
    source_namespace: "istio-system"
    source_workload: "istio-ingressgateway"
    destination_name: "productpage-v1-76589d9fdc-ptnt9"
    destination_app: "productpage"
  }
  trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536"
  receiveTimestamp: "2020-04-29T03:07:14.362416217Z"
  spanId: "43226343ca2bb2b1"
  traceSampled: true
  logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver"
  receiveTimestamp: "2020-04-28T19:55:32.185229100Z"
}

Interprete a telemetria do Cloud Service Mesh

As secções seguintes explicam como verificar o estado da sua malha e rever a várias telemetrias que contêm detalhes úteis para ajudar na resolução de problemas.

Interprete as métricas do plano de controlo

Managed Cloud Service Mesh

O Cloud Service Mesh com um plano de controlo do Cloud Service Mesh gerido não suporta métricas do plano de controlo.

Gerido `istiod`

O Cloud Service Mesh com um plano de controlo istiod gerido não suporta a inspeção de métricas do plano de controlo nesta secção.

No cluster

Quando instala o Cloud Service Mesh com o plano de controlo no cluster, istiod exporta métricas para o Google Cloud Observability para monitorização, por predefinição. istiod prefixa estas métricas com istio.io/control e fornece estatísticas sobre o estado do plano de controlo, como o número de proxies ligados a cada instância do plano de controlo, eventos de configuração, envios e validações.

Observe ou resolva problemas do plano de controlo através dos seguintes passos.

Carregue um painel de controlo de exemplo:

git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh

Instale o painel de controlo do Cloud Service Mesh:

gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json

Procure um painel de controlo com o nome Istio Control Plane Dashboard na lista. Para mais informações, consulte o artigo Ver o painel de controlo instalado.

Para ver a lista completa de métricas disponíveis, consulte o artigo Métricas exportadas.

Diagnostique atrasos na configuração

Managed Cloud Service Mesh

O Cloud Service Mesh com um plano de controlo do Cloud Service Mesh gerido não suporta o diagnóstico de atrasos na configuração.

Gerido `istiod`

O Cloud Service Mesh com um plano de controlo do Istiod gerido não suporta o diagnóstico de atrasos na configuração.

No cluster

Os passos seguintes explicam como usar a métrica pilot_proxy_convergence_time para diagnosticar um atraso entre uma alteração de configuração e a convergência de todos os proxies.

Executar um comando shell num pod:

kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s

Aceda a localhost:15014 e grep para convergence nas métricas:
```
curl http://localhost:15014/metrics | grep convergence
```

Interprete registos de tráfego

As informações seguintes explicam como usar os registos de tráfego para resolver problemas de ligação. Os registos de tráfego estão ativados por predefinição.

O Cloud Service Mesh exporta dados para registos de tráfego que podem ajudar a depurar os seguintes tipos de problemas:

Fluxo de tráfego e falhas
Encaminhamento de pedidos ponto a ponto

Os registos de tráfego estão ativados por predefinição para instalações do Cloud Service Mesh no Google Kubernetes Engine. Pode ativar os registos de tráfego executando novamente o asmcli install. Use as mesmas opções que instalou originalmente, mas omita a sobreposição personalizada que desativou o Stackdriver.

Existem dois tipos de registos de tráfego:

Os registos de acesso ao servidor dão uma vista do lado do servidor dos pedidos. Estão localizadas em server-accesslog-stackdriver, anexadas ao recurso k8s_container monitorizado. Use a seguinte sintaxe de URL para apresentar registos de acesso do lado do servidor:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
Os registos de acesso do cliente oferecem uma vista dos pedidos do lado do cliente. Estão localizadas em client-accesslog-stackdriver, anexadas ao recurso monitorizado k8s_pod. Use a seguinte sintaxe de URL para apresentar registos de acesso do lado do cliente:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```

Os registos de acesso contêm as seguintes informações:

Propriedades do pedido HTTP, como ID, URL, tamanho, latência e cabeçalhos comuns.
Informações da carga de trabalho de origem e destino, como o nome, o espaço de nomes, a identidade e as etiquetas comuns.
Informações canónicas do serviço e da revisão de origem e destino.
Se a monitorização estiver ativada, os registos contêm informações de rastreio, como amostragem, ID de rastreio e ID de intervalo.

Os registos de tráfego podem conter as seguintes etiquetas:

route_name
upstream_cluster
X-Envoy-Original-Path

Este é um exemplo de uma entrada de registo:

{
  "insertId": "1j84zg8g68vb62z",
  "httpRequest": {
    "requestMethod": "GET",
    "requestUrl": "http://35.235.89.201:80/productpage",
    "requestSize": "795",
    "status": 200,
    "responseSize": "7005",
    "remoteIp": "10.168.0.26:0",
    "serverIp": "10.36.3.153:9080",
    "latency": "0.229384205s",
    "protocol": "http"
  },
  "resource": {
    "type": "k8s_container",
    "labels": {
      "cluster_name": "istio-e2e22",
      "namespace_name": "istio-bookinfo-1-68819",
      "container_name": "productpage",
      "project_id": "***",
      "location": "us-west2-a",
      "pod_name": "productpage-v1-64794f5db4-8xbtf"
    }
  },
  "timestamp": "2020-08-13T21:37:42.963881Z",
  "severity": "INFO",
  "labels": {
    "protocol": "http",
    "upstream_host": "127.0.0.1:9080",
    "source_canonical_service": "istio-ingressgateway",
    "source_namespace": "istio-system",
    "x-envoy-original-path": "",
    "source_canonical_revision": "latest",
    "connection_id": "32",
    "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_version": "v1",
    "destination_workload": "productpage-v1",
    "source_workload": "istio-ingressgateway",
    "destination_canonical_revision": "v1",
    "mesh_uid": "cluster.local",
    "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account",
    "x-envoy-original-dst-host": "",
    "service_authentication_policy": "MUTUAL_TLS",
    "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage",
    "response_flag": "-",
    "log_sampled": "false",
    "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local",
    "destination_name": "productpage-v1-64794f5db4-8xbtf",
    "destination_canonical_service": "productpage",
    "destination_namespace": "istio-bookinfo-1-68819",
    "source_name": "istio-ingressgateway-6845f6d664-lnfvp",
    "source_app": "istio-ingressgateway",
    "destination_app": "productpage",
    "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4",
    "route_name": "default"
  },
  "logName": "projects/***/logs/server-accesslog-stackdriver",
  "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f",
  "receiveTimestamp": "2020-08-13T21:37:48.758673203Z",
  "spanId": "633831cb1fda4fd5",
  "traceSampled": true
}

Pode usar este registo de várias formas:

Integre-se com o Cloud Trace, que é uma funcionalidade opcional no Cloud Service Mesh.
Exporte registos de tráfego para o BigQuery, onde pode executar consultas como selecionar todos os pedidos que demoram mais de 5 segundos.
Crie métricas baseadas em registos.
Resolva problemas de erros 404 e 503

Resolva problemas de erros `404` e `503`

O exemplo seguinte explica como usar este registo para resolver problemas quando um pedido falha com um código de resposta 404 ou 503.

No registo de acesso do cliente, pesquise uma entrada semelhante à seguinte:

httpRequest: {
requestMethod: "GET"
requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php"
requestSize: "2088"
status: 404
responseSize: "75"
remoteIp: "10.168.0.26:34165"
serverIp: "10.36.3.149:8080"
latency: "0.000371440s"
protocol: "http"
}

Navegue para as etiquetas na entrada do registo de acesso. Encontre o campo response_flag semelhante ao seguinte:
```
response_flag: "NR"
```
O valor NR é um acrónimo de NoRoute, o que significa que não foi encontrada nenhuma rota para o destino ou que não existia nenhuma cadeia de filtros correspondente para uma ligação a jusante. Da mesma forma, também pode usar a etiqueta response_flag para resolver problemas de erros 503.
Se vir erros 503 nos registos de acesso do cliente e do servidor, verifique se os nomes das portas definidos para cada serviço correspondem ao nome do protocolo em utilização entre eles. Por exemplo, se um cliente binário golang se ligar a um servidor golang através de HTTP, mas a porta tiver o nome http2, o protocolo não é negociado automaticamente corretamente.

Para mais informações, consulte as flags de resposta.

Interprete os registos de acesso do Envoy

Os passos seguintes explicam como usar os registos de acesso do Envoy para mostrar o tráfego entre ambas as extremidades de uma ligação para fins de resolução de problemas.

Os registos de acesso do Envoy são úteis para diagnosticar problemas como:

Fluxo de tráfego e falhas
Encaminhamento de pedidos ponto a ponto

Os registos de acesso do Envoy não estão ativados por predefinição no Cloud Service Mesh e podem ser ativados para os clusters numa malha.

Pode resolver problemas de ligação ou falhas de pedidos gerando atividade na sua aplicação que aciona um pedido HTTP e, em seguida, inspecionando o pedido associado nos registos de origem ou de destino.

Se for acionado um pedido e este aparecer nos registos do proxy de origem, significa que o redirecionamento de tráfego iptables está a funcionar corretamente e o proxy do Envoy está a processar o tráfego. Se vir erros nos registos, gere um despejo da configuração do Envoy e verifique a configuração do cluster do Envoy para garantir que está correta. Se vir o pedido, mas o registo não tiver erros, verifique os registos do proxy de destino.

Se o pedido aparecer nos registos do proxy de destino, indica que a malha está a funcionar corretamente. Se vir um erro, execute um despejo da configuração do Envoy e verifique os valores corretos para a porta de tráfego definida na configuração do ouvinte.

Se o problema persistir após executar os passos anteriores, o Envoy pode não conseguir negociar automaticamente o protocolo entre o sidecar e o respetivo pod de aplicação. Certifique-se de que o nome da porta do serviço Kubernetes, por exemplo, http-80, corresponde ao protocolo usado pela aplicação.

Use o Explorador de registos para consultar registos

Pode usar a interface do explorador de registos para consultar registos de acesso do Envoy específicos. Por exemplo, para consultar todos os pedidos que têm o MULTUAL_TLS ativado e usam o protocolo grpc, acrescente o seguinte à consulta dos registos de acesso ao servidor:

labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"

Defina uma política de registo de acesso

Managed Cloud Service Mesh

Para configurar os registos de acesso para a Cloud Service Mesh com um plano de controlo da Cloud Service Mesh gerido, consulte o artigo Ativar registos de acesso.

Gerido `istiod`

Para configurar os registos de acesso para a Cloud Service Mesh com um plano de controlo do Istiod gerido, consulte o artigo Ativar registos de acesso.

No cluster

Para definir uma política de registo de acesso para a Cloud Service Mesh com o plano de controlo no cluster:

Crie um ficheiro de sobreposição personalizado IstioOperator que inclua os valores AccessLogPolicyConfig aplicáveis ao seu cenário.
Transmita este ficheiro ao asmcli através da opção --custom_overlay para atualizar a configuração do plano de controlo no cluster. Para obter informações sobre a execução do asmcli install com um ficheiro de sobreposição personalizado, consulte o artigo Instale com funcionalidades opcionais.

Atenção: se personalizou a instalação anterior, precisa das mesmas personalizações quando reinstalar o plano de controlo para incluir o ficheiro com as definições AccessLogPolicyConfig. A omissão de um ficheiro de sobreposição resulta numa instalação bem-sucedida. No entanto, a sua malha de serviços tem uma configuração diferente da pretendida, porque os valores omitidos são repostos para os predefinidos quando o plano de controlo é reimplementado.

Veja informações específicas do serviço ou da carga de trabalho

Se tiver um problema com um serviço ou uma carga de trabalho específicos, em vez de um problema em toda a malha, inspecione os proxies Envoy individuais e recolha informações relevantes dos mesmos. Para reunir informações sobre uma carga de trabalho específica e os respetivos proxies, pode usar o pilot-agent:

kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE

No exemplo, SCOPE é uma das seguintes opções:

certs - Certificados na instância do Envoy
clusters – Clusters com o Envoy configurado
config_dump: despeja a configuração do Envoy
listeners – Ouvintes com o Envoy configurado
logging – Veja e altere as definições de registo
stats – Estatísticas do Envoy
stats/prometheus – Estatísticas do Envoy como registos do Prometheus

Veja os estados dos sockets de proxy

Pode examinar diretamente o estado das entradas do proxy Envoy através do seguinte processo.

Apresente uma lista de sockets estabelecidos, incluindo sockets no estado TIME_WAIT que podem afetar negativamente a escalabilidade se o respetivo número for elevado:
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

Apresentar um resumo das estatísticas de sockets:

kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s

Para mais informações, consulte o artigo Uma introdução ao comando ss.

`istio-proxy` e `istio-init` registos

Além disso, obtenha os registos do istio-proxy e reveja o respetivo conteúdo para verificar se existem erros que possam sugerir a causa do problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Pode fazer o mesmo para o contentor init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

O que se segue?

Faça a integração com o Cloud Trace. O Cloud Trace é uma funcionalidade opcional no Cloud Service Mesh.
Exporte registos de tráfego para o BigQuery.
Crie métricas baseadas em registos.

Peça registos de proxy

Ativar e desativar registos de acesso

Managed Cloud Service Mesh

Registos de acesso do Envoy

Registos de tráfego

Ambos

Gerido istiod

Registos de acesso do Envoy

Registos de tráfego

No cluster

Registos de acesso do Envoy

Registos de tráfego

Visualizar registos de acesso

Registos de acesso do Envoy

Linha de comandos

Logs Explorer

Registos de tráfego

Registos do servidor

Registos do cliente

Interprete a telemetria do Cloud Service Mesh

Interprete as métricas do plano de controlo

Managed Cloud Service Mesh

Gerido istiod

No cluster

Diagnostique atrasos na configuração

Managed Cloud Service Mesh

Gerido istiod

No cluster

Interprete registos de tráfego

Resolva problemas de erros 404 e 503

Interprete os registos de acesso do Envoy

Use o Explorador de registos para consultar registos

Defina uma política de registo de acesso

Managed Cloud Service Mesh

Gerido istiod

No cluster

Veja informações específicas do serviço ou da carga de trabalho

Veja os estados dos sockets de proxy

istio-proxy e istio-init registos

O que se segue?

Gerido `istiod`

Gerido `istiod`

Gerido `istiod`

Resolva problemas de erros `404` e `503`

Gerido `istiod`

`istio-proxy` e `istio-init` registos