Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Solicitar registros de proxy

Cloud Service Mesh admite dos tipos de registros de acceso en Cloud Logging: registros de tráfico (también conocidos como registros de acceso de Observabilidad de Google Cloud) y registros de acceso de Envoy. En esta página se explica cómo habilitar, inhabilitar, ver e interpretar estos registros. Ten en cuenta que los registros de tráfico están habilitados de forma predeterminada.

Habilitar e inhabilitar los registros de acceso

Cloud Service Mesh gestionado

Registros de acceso de Envoy

Ejecuta el siguiente comando para habilitar los registros de acceso de Envoy e inhabilitar los registros de tráfico:

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

Tenga en cuenta que el nombre del proveedor del registro de tráfico es stackdriver.

Registros de tráfico

De forma predeterminada, los registros de tráfico están habilitados y los registros de acceso de Envoy están inhabilitados. Si ya has habilitado los registros de acceso de Envoy y quieres habilitar los registros de tráfico y deshabilitar los registros de acceso de Envoy, ejecuta el siguiente 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 habilitar los registros de acceso y de tráfico de Envoy, ejecuta el siguiente 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 inhabilitar los registros de acceso y de tráfico de Envoy, ejecuta el siguiente 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

Gestionado por `istiod`

Registros de acceso de Envoy

Ejecuta los siguientes comandos para habilitar el registro de acceso de Envoy:

Ejecuta el siguiente comando para añadir 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

donde release-channel es tu canal de lanzamiento (asm-managed, asm-managed-stable o asm-managed-rapid).

Ejecuta el siguiente comando para ver el configmap:

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

Para comprobar que el registro de acceso está habilitado, asegúrate de que la línea accessLogFile: /dev/stdout aparece en la sección mesh:.
```
...
apiVersion: v1
data:
  mesh: |
    ....
    accessLogFile: /dev/stdout
...
```

Registros de tráfico

Los registros de tráfico están habilitados de forma predeterminada.

En el clúster

Registros de acceso de Envoy

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

Para obtener más información, consulta Habilitar el registro de acceso de Envoy.

Registros de tráfico

Los registros de tráfico están habilitados de forma predeterminada, a menos que Cloud Service Mesh esté instalado en Google Distributed Cloud con Istio CA (anteriormente conocido como Citadel).

Para habilitar los registros de tráfico en Google Distributed Cloud con Istio CA cuando instales Cloud Service Mesh en el clúster, usa la marca --option stackdriver. También puedes habilitar los registros de tráfico en Google Distributed Cloud con Istio CA después de instalar Cloud Service Mesh en el clúster.

Ver registros de acceso

Registros de acceso de Envoy

Línea de comandos

Para ver los registros de acceso de Envoy en el registro istio-proxy, ejecuta el siguiente comando:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Explorador de registros

Para ver los registros de acceso de Envoy en el Explorador de registros, sigue estos pasos:

Ve al explorador de registros:

Ir al Explorador de registros
Selecciona el Google Cloud proyecto adecuado.
Ejecuta la siguiente 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"

Registros de tráfico

Para ver los registros de tráfico en el Explorador de registros, sigue estos pasos:

Ve al explorador de registros:

Ir al Explorador de registros
Selecciona el Google Cloud proyecto adecuado.

Ejecuta la siguiente consulta en función de si estás viendo los registros de acceso del cliente o del servidor:

Registros de servidor

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

Registros de clientes

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

Para ver los registros de tráfico de un servicio en la página de Cloud Service Mesh durante un periodo específico, sigue estos pasos:

En la consola, ve a la página Cloud Service Mesh. Google Cloud

Ir a la página Cloud Service Mesh
En Servicios, selecciona el nombre del servicio que quieras inspeccionar.
Ve a la página Métricas.
Especifica un periodo en el menú desplegable Periodo o define un periodo personalizado con la cronología.
En Seleccionar una opción de filtro, haz clic en Ver registros de tráfico.

El registro de tráfico se llama server-accesslog-stackdriver y se adjunta al recurso monitorizado correspondiente (k8s_container o gce_instance) que utiliza tu servicio. El registro de tráfico contiene la siguiente información:

Propiedades de las solicitudes HTTP, como el ID, la URL, el tamaño, la latencia y los encabezados comunes.
Información de la carga de trabajo de origen y de destino, como el nombre, el espacio de nombres, la identidad y las etiquetas comunes.
Si la monitorización está habilitada, se incluye información de la traza, como el muestreo, el ID de la traza y el ID del intervalo.

Una entrada de registro de ejemplo tiene el siguiente aspecto:

{
  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"
}

Interpretar la telemetría de Cloud Service Mesh

En las siguientes secciones se explica cómo comprobar el estado de tu malla y revisar la telemetría, que contiene detalles útiles para ayudarte a solucionar problemas.

Interpretar las métricas del plano de control

Cloud Service Mesh gestionado

Cloud Service Mesh con un plano de control de Cloud Service Mesh gestionado no admite métricas del plano de control.

Gestionado por `istiod`

Cloud Service Mesh con un plano de control istiod gestionado no admite la inspección de métricas del plano de control que se describe en esta sección.

En el clúster

Cuando se instala Cloud Service Mesh con el plano de control en el clúster, istiod exporta métricas a Google Cloud Observability para la monitorización de forma predeterminada. istiod prefija estas métricas con istio.io/control y proporciona información valiosa sobre el estado del plano de control, como el número de proxies conectados a cada instancia del plano de control, los eventos de configuración, los envíos y las validaciones.

Observa o soluciona problemas del plano de control siguiendo estos pasos.

Carga un panel de control de ejemplo:

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

Instala el panel de control de Cloud Service Mesh:

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

Busca un panel de control llamado Istio Control Plane Dashboard en la lista. Para obtener más información, consulta Ver el panel de control instalado.

Para ver la lista completa de métricas disponibles, consulte Métricas exportadas.

Diagnosticar retrasos en la configuración

Cloud Service Mesh gestionado

Cloud Service Mesh con un plano de control de Cloud Service Mesh gestionado no admite el diagnóstico de retrasos en la configuración.

Gestionado por `istiod`

Cloud Service Mesh con un plano de control istiod gestionado no admite el diagnóstico de retrasos en la configuración.

En el clúster

En los pasos siguientes se explica cómo usar la métrica pilot_proxy_convergence_time para diagnosticar un retraso entre un cambio de configuración y la convergencia de todos los proxies.

Ejecuta un comando de shell en un 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

Acceso a localhost:15014 y grep para convergence en las métricas:
```
curl http://localhost:15014/metrics | grep convergence
```

Interpretar registros de tráfico

En este artículo se explica cómo usar los registros de tráfico para solucionar problemas de conexión. Los registros de tráfico están habilitados de forma predeterminada.

Cloud Service Mesh exporta datos a registros de tráfico que pueden ayudarte a depurar los siguientes tipos de problemas:

Flujo de tráfico y errores
Enrutamiento de solicitudes de extremo a extremo

Los registros de tráfico están habilitados de forma predeterminada en las instalaciones de Cloud Service Mesh en Google Kubernetes Engine. Para habilitar los registros de tráfico, vuelve a ejecutar asmcli install. Usa las mismas opciones que en la instalación original, pero omite la superposición personalizada que inhabilitó Stackdriver.

Hay dos tipos de registros de tráfico:

Los registros de acceso al servidor ofrecen una vista de las solicitudes del lado del servidor. Se encuentran en server-accesslog-stackdriver, adjuntos al recurso k8s_container monitorizado. Utilice la siguiente sintaxis de URL para mostrar los registros de acceso del lado del servidor:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
```
Los registros de acceso de clientes ofrecen una vista de las solicitudes del lado del cliente. Se encuentran en client-accesslog-stackdriver, adjuntos al recurso monitorizado k8s_pod. Usa la siguiente sintaxis de URL para mostrar los registros de acceso del lado del cliente:
```
https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
```

Los registros de acceso contienen la siguiente información:

Propiedades de las solicitudes HTTP, como el ID, la URL, el tamaño, la latencia y los encabezados comunes.
Información de la carga de trabajo de origen y de destino, como el nombre, el espacio de nombres, la identidad y las etiquetas comunes.
Información canónica del servicio y la revisión de origen y destino.
Si la monitorización está habilitada, los registros contienen información de la traza, como el muestreo, el ID de traza y el ID de intervalo.

Los registros de tráfico pueden contener las siguientes etiquetas:

route_name
upstream_cluster
X-Envoy-Original-Path

Este es un ejemplo de entrada de registro:

{
  "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
}

Puedes usar este registro de varias formas:

Integración con Cloud Trace, que es una función opcional de Cloud Service Mesh.
Exporta los registros de tráfico a BigQuery, donde puedes ejecutar consultas como seleccionar todas las solicitudes que tardan más de 5 segundos.
Crea métricas basadas en registros.
Solucionar errores 404 y 503

Solucionar errores `404` y `503`

En el siguiente ejemplo se explica cómo usar este registro para solucionar problemas cuando una solicitud falla con un código de respuesta 404 o 503.

En el registro de acceso del cliente, busca una entrada como la siguiente:

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"
}

Desplázate hasta las etiquetas de la entrada del registro de acceso. Busca el campo response_flag que tenga este aspecto:
```
response_flag: "NR"
```
El valor NR es un acrónimo de NoRoute, que significa que no se ha encontrado ninguna ruta para el destino o que no había ninguna cadena de filtros coincidente para una conexión de nivel inferior. Del mismo modo, puede usar la etiqueta response_flag para solucionar problemas de 503.
Si ves errores 503 en los registros de acceso del cliente y del servidor, comprueba que los nombres de los puertos definidos para cada servicio coincidan con el nombre del protocolo que se usa entre ellos. Por ejemplo, si un cliente binario de Go se conecta a un servidor de Go mediante HTTP, pero el puerto se llama http2, el protocolo no se negociará automáticamente correctamente.

Para obtener más información, consulta los flags de respuesta.

Interpretar los registros de acceso de Envoy

En los pasos que se indican a continuación se explica cómo usar los registros de acceso de Envoy para mostrar el tráfico entre los dos extremos de una conexión con fines de solución de problemas.

Los registros de acceso de Envoy son útiles para diagnosticar problemas como los siguientes:

Flujo de tráfico y errores
Enrutamiento de solicitudes de extremo a extremo

Los registros de acceso de Envoy no están habilitados de forma predeterminada en Cloud Service Mesh y se pueden habilitar para los clústeres de una malla.

Para solucionar problemas de conexión o de solicitudes, genera actividad en tu aplicación que active una solicitud HTTP y, a continuación, inspecciona la solicitud asociada en los registros de origen o de destino.

Si se activa una solicitud y aparece en los registros del proxy de origen, significa que la redirección del tráfico de iptables funciona correctamente y que el proxy de Envoy gestiona el tráfico. Si ve errores en los registros, genere un volcado de configuración de Envoy y compruebe la configuración del clúster de Envoy para asegurarse de que es correcta. Si ves la solicitud, pero el registro no tiene errores, consulta los registros del proxy de destino.

Si la solicitud aparece en los registros del proxy de destino, significa que la malla funciona correctamente. Si aparece un error, ejecuta un volcado de configuración de Envoy y verifica los valores correctos del puerto de tráfico definido en la configuración del listener.

Si el problema persiste después de seguir los pasos anteriores, es posible que Envoy no pueda negociar automáticamente el protocolo entre el sidecar y su pod de aplicación. Asegúrate de que el nombre del puerto del servicio de Kubernetes, por ejemplo, http-80, coincida con el protocolo que usa la aplicación.

Usar Explorador de registros para consultar registros

Puedes usar la interfaz del explorador de registros para consultar registros de acceso de Envoy específicos. Por ejemplo, para consultar todas las solicitudes que tienen MULTUAL_TLS habilitado y usan el protocolo grpc, añade lo siguiente a la consulta de los registros de acceso al servidor:

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

Definir una política de registro de acceso

Cloud Service Mesh gestionado

Para configurar los registros de acceso de Cloud Service Mesh con un plano de control gestionado de Cloud Service Mesh, consulta Habilitar registros de acceso.

Gestionado por `istiod`

Para configurar los registros de acceso de Cloud Service Mesh con un plano de control de istiod gestionado, consulta Habilitar registros de acceso.

En el clúster

Para definir una política de registro de acceso para Cloud Service Mesh con el plano de control en el clúster, sigue estos pasos:

Cree un archivo de superposición personalizada IstioOperator que incluya los valores AccessLogPolicyConfig aplicables a su caso.
Pasa este archivo a asmcli con la opción --custom_overlay para actualizar la configuración del plano de control del clúster. Para obtener información sobre cómo ejecutar asmcli install con un archivo de superposición personalizado, consulta el artículo sobre cómo instalar con funciones opcionales.

Advertencia: Si has personalizado la instalación anterior, debes aplicar las mismas personalizaciones al reinstalar el plano de control para incluir el archivo con los ajustes de AccessLogPolicyConfig. Si se omite un archivo de superposición, la instalación se realizará correctamente. Sin embargo, tu malla de servicios tendrá una configuración diferente a la que querías, ya que los valores omitidos se restablecerán a los predeterminados cuando se vuelva a implementar el plano de control.

Ver información específica de un servicio o una carga de trabajo

Si tienes un problema con un servicio o una carga de trabajo específicos en lugar de con toda la malla, inspecciona los proxies de Envoy individuales y recoge información relevante de ellos. Para obtener información sobre una carga de trabajo concreta y sus proxies, puedes usar pilot-agent:

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

En el ejemplo, SCOPE es uno de los siguientes:

certs: certificados de la instancia de Envoy
clusters: clústeres con Envoy configurado
config_dump: muestra la configuración de Envoy.
listeners: listeners con Envoy configurado
logging: ver y cambiar los ajustes de registro
stats: estadísticas de Envoy
stats/prometheus: estadísticas de Envoy como registros de Prometheus

Ver estados de sockets proxy

Puedes examinar directamente el estado de los sockets proxy de Envoy siguiendo este proceso.

Muestra una lista de los sockets establecidos, incluidos los sockets en el estado TIME_WAIT, que pueden afectar negativamente a la escalabilidad si su número es elevado:
```
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
```

Muestra un resumen de las estadísticas de los sockets:

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

Para obtener más información, consulta Introducción al comando ss.

Registros de `istio-proxy` y `istio-init`

Además, obtenga los registros de istio-proxy y revise su contenido para detectar errores que puedan indicar la causa del problema:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy

Puedes hacer lo mismo con el contenedor init:

kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init

Siguientes pasos

Integración con Cloud Trace Cloud Trace es una función opcional de Cloud Service Mesh.
Exportar registros de tráfico a BigQuery.
Crea métricas basadas en registros.

Solicitar registros de proxy

Habilitar e inhabilitar los registros de acceso

Cloud Service Mesh gestionado

Registros de acceso de Envoy

Registros de tráfico

Ambos

Gestionado por istiod

Registros de acceso de Envoy

Registros de tráfico

En el clúster

Registros de acceso de Envoy

Registros de tráfico

Ver registros de acceso

Registros de acceso de Envoy

Línea de comandos

Explorador de registros

Registros de tráfico

Registros de servidor

Registros de clientes

Interpretar la telemetría de Cloud Service Mesh

Interpretar las métricas del plano de control

Cloud Service Mesh gestionado

Gestionado por istiod

En el clúster

Diagnosticar retrasos en la configuración

Cloud Service Mesh gestionado

Gestionado por istiod

En el clúster

Interpretar registros de tráfico

Solucionar errores 404 y 503

Interpretar los registros de acceso de Envoy

Usar Explorador de registros para consultar registros

Definir una política de registro de acceso

Cloud Service Mesh gestionado

Gestionado por istiod

En el clúster

Ver información específica de un servicio o una carga de trabajo

Ver estados de sockets proxy

Registros de istio-proxy y istio-init

Siguientes pasos

Gestionado por `istiod`

Gestionado por `istiod`

Gestionado por `istiod`

Solucionar errores `404` y `503`

Gestionado por `istiod`

Registros de `istio-proxy` y `istio-init`