Habilita funciones opcionales en el plano de control en el clúster

En esta página, se describe cómo habilitar funciones opcionales en un plano de control en el clúster. Para obtener información sobre el plano de control administrado, consulta Configura Anthos Service Mesh administrado.

Cuando instalas Anthos Service Mesh, las funciones que están habilitadas de forma predeterminada difieren según la plataforma. Puedes habilitar funciones opcionales si incluyes un archivo de superposición cuando instalas (o actualizas) Anthos Service Mesh. Un archivo de superposición es un archivo YAML que contiene una recurso personalizado (CR) IstioOperator que usas para configurar el plano de control. Puedes anular la configuración predeterminada y habilitar una función opcional o inhabilitar una función predeterminada en un archivo de superposición. Especifica una función por archivo de superposición. Puedes agregar capas a más superposiciones, y cada archivo superpuesto anula la configuración de las capas anteriores.

Acerca de los archivos de superposición

Los archivos de superposición de esta página se encuentran en el paquete anthos-service-mesh en GitHub. Estos archivos contienen personalizaciones comunes de la configuración predeterminada. Puedes usar estos archivos tal como están o puedes realizar cambios adicionales según sea necesario.

Cuando instalas Anthos Service Mesh con la secuencia de comandos asmcli que proporciona Google, puedes especificar uno o más archivos de superposición con la --option o las opciones --custom_overlay. Si no necesitas realizar cambios en los archivos del repositorio anthos-service-mesh, puedes usar --option y la secuencia de comandos recupera el archivo de GitHub. De lo contrario, puedes realizar cambios en el archivo de superposición y, luego, usar la opción --custom_overlay para pasarlo a la secuencia de comandos asmcli.

No incluyas varios CR en un archivo superpuesto Crea archivos superpuestos separados para cada CR
varios CR en un yaml archivos yaml separados para cada CR

Cómo habilitar funciones opcionales

Los siguientes ejemplos están simplificados para que solo se muestren con las superposiciones personalizadas a fin de habilitar funciones opcionales. Reemplaza OTHER_FLAGS por las otras opciones de la línea de comandos.

La secuencia de comandos asmcli install proporciona dos formas de habilitar una función opcional. El método que uses dependerá de si necesitas hacer cambios en el archivo de superposición.

  • Usa --option cuando no necesites realizar ningún cambio en el archivo de superposición. Con --option, asmcli recupera el archivo del repositorio de GitHub, por lo que debes tener una conexión a Internet.

    ./asmcli install \
      OTHER_FLAGS \
      --option OPTION_NAME
    

    Reemplaza OPTION_NAME por la opción que deseas habilitar. Para obtener una lista de opciones, consulta el paquete anthos-service-mesh.

  • Usa --custom_overlay cuando necesites personalizar el archivo de superposición.

    ./asmcli install \
      OTHER_FLAGS \
      --custom_overlay PATH_TO_FILE
    

    Reemplaza PATH_TO_FILE por la ruta de acceso al archivo de superposición que deseas usar.

YAML para características opcionales

En las siguientes secciones, se proporciona el archivo YAML para habilitar características opcionales y compatibles.

Modo STRICT de mTLS

Se quitó la configuración global.mtls.enabled de la CR de IstioOperator para evitar problemas con las actualizaciones y proporcionar una instalación más flexible. Para habilitar mTLS STRICT, configura una política de autenticación de pares.

Imagen de proxy distroless

Como práctica recomendada, debes restringir el contenido de un entorno de ejecución de un contenedor solo a los paquetes necesarios. Este enfoque mejora la seguridad y la relación entre las señales y el ruido de los analizadores de vulnerabilidades y riesgos comunes (CVE). Istio proporciona imágenes de proxy basadas en imágenes base distroless.

En la siguiente configuración, se habilitan las imágenes distroless para toda Anthos Service Mesh. Un cambio de tipo imagen requiere que cada pod se reinicie y se vuelva a insertar para que se aplique.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      image:
        imageType: distroless

La imagen distroless no contiene ningún objeto binario distinto del proxy. Por lo tanto, no es posible exec una shell ni usar curl, ping u otras utilidades de depuración dentro del contenedor. Si intentas ejecutar una shell, verás el siguiente error.

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "<container-id>"
OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown

Si necesitas acceso a estas herramientas para pods específicos, puedes anular imageType con la siguiente anotación de pod.

sidecar.istio.io/proxyImageType: debug

Después de cambiar el tipo de imagen de una implementación a través de la anotación, la implementación debe reiniciarse.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Para la mayoría de los tipos de depuración de proxy, se debe usar istioctl proxy-cmd, que no requiere una imagen base de depuración.

Usa una superposición personalizada para el registro personalizado

Puedes usar una superposición personalizada para los registros personalizados, por ejemplo, si necesitas instalar Anthos Service Mesh desde un registro de contenedores personalizado. Por ejemplo:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  hub: {private_registry_url}

A continuación, se muestra una lista de imágenes de Anthos Service Mesh que debes duplicar en Container Registry personalizado:

  • Install-cni: gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
  • Plano de datos administrado: gcr.io/gke-release/asm/mdp:1.14.6-asm.16
  • Piloto: gcr.io/gke-release/asm/pilot:1.14.6-asm.16
  • Proxyv2: gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16

Agrega imágenes a un registro privado

Para enviar imágenes de Anthos Service Mesh a un registro privado, completa los siguientes pasos.

  1. Extrae las imágenes de Anthos Service Mesh:
    docker pull gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
    docker pull gcr.io/gke-release/asm/mdp:1.14.6-asm.16
    docker pull gcr.io/gke-release/asm/pilot:1.14.6-asm.16
    docker pull gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
    
  2. Crea una variable para la URL de registro privado:
    export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
    
    Reemplaza PRIVATE_REGISTRY_URL con la URL de tu registro privado.
  3. Etiqueta las imágenes con la URL de tu registro privado:
    docker tag gcr.io/gke-release/asm/install-cni:1.14.6-asm.16 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
    docker tag gcr.io/gke-release/asm/mdp:1.14.6-asm.16 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16
    docker tag gcr.io/gke-release/asm/pilot:1.14.6-asm.16 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16
    docker tag gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16 \
     ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
    
  4. Envía las imágenes etiquetadas al registro privado:
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/install-cni:1.14.6-asm.16
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/mdp:1.14.6-asm.16
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/pilot:1.14.6-asm.16
    docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/proxyv2:1.14.6-asm.16
    
  5. Opcional: Si usas un servicio canónico, agrega las imágenes del servicio canónico a tu registro privado.
    1. Extrae las imágenes de servicio canónicas de Anthos Service Mesh:
              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0
              docker pull gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              
    2. Etiqueta las imágenes con la URL de tu registro privado:
              docker tag gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0
              docker tag gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              
    3. Envía las imágenes etiquetadas al registro privado:
              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/kube-rbac-proxy:v0.5.0
              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/gke-release/asm/canonical-service-controller:1.10.3-asm.16
              

Si puedes extraer las imágenes etiquetadas desde el registro privado, el procedimiento se realizó correctamente.

Dirige Envoy a stdout

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

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

Cloud Trace

Cloud Trace está disponible con las instalaciones de Anthos Service Mesh en las siguientes plataformas:

  • GKE en Google Cloud
  • Clústeres de GKE Enterprise locales si realizas la instalación con la autoridad certificadora de Anthos Service Mesh (CA de Mesh)

Para obtener información detallada sobre los precios, consulta la página de precios de Cloud Trace.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
  values:
    global:
      proxy:
        tracer: stackdriver

La tasa de muestreo predeterminada es del 1%, pero puedes anular el valor predeterminado si especificas un valor tracing.sampling. El valor debe estar en el rango de 0.0 a 100.0 con una precisión de 0.01. Por ejemplo, para hacer un seguimiento de 5 solicitudes de cada 10,000, usa 0.05.

En el siguiente ejemplo, se muestra una tasa de muestreo del 100% (que solo usarías con fines de demostración o solución de problemas).

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100
  values:
    global:
      proxy:
        tracer: stackdriver

Ten en cuenta que, actualmente, la configuración del rastreador es parte de la configuración de arranque del proxy, por lo que el pod debe reiniciarse y volver a insertarse para aplicar la actualización del rastreador. Por ejemplo, puedes usar el siguiente comando para reiniciar los pods que pertenecen a una implementación:

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Propagación del contexto de seguimiento

Aunque los proxies de sidecar pueden enviar de forma automática intervalos de seguimiento, necesitan algunas sugerencias para unir todo el seguimiento. Las aplicaciones deben propagar los encabezados HTTP adecuados para que cuando los proxies envíen información de intervalo, los intervalos puedan correlacionarse de forma correcta en un solo seguimiento.

Para ello, una aplicación debe recopilar y propagar los siguientes encabezados de la solicitud entrante en cualquier solicitud saliente. La configuración de seguimiento de Anthos Service Mesh con Stackdriver aceptará cualquiera de los siguientes formatos de encabezado y propagará todos los formatos siguientes:

  • B3 (x-b3-traceid, x-b3-spanid, x-b3parentspanid, x-b3-sampled, x-b3-flags)
  • W3C TraceContext (traceparent)
  • Google Cloud Trace (x-cloud-trace-context)
  • gRPC TraceBin (grpc-trace-bin)

Esto significa que tus aplicaciones pueden usar cualquiera de esos formatos para propagar el contexto de seguimiento,y los seguimientos se generarán y se configurarán en Stackdriver de manera apropiada.

Ejemplo

Aquí hay un ejemplo de solicitud HTTP-Get con un encabezado traceparent en la solicitud original. Observa los encabezados de contexto de seguimiento adicionales que agregó el proxy.

$ kubectl exec -it sleep-557747455f-n6flv -- curl "httpbin:8000/anything?freeform=" -H "accept: application/json" -H "Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01" -vv
*   Trying 10.12.3.52:8000...
* Connected to httpbin (10.12.3.52) port 8000 (#0)
> GET /anything?freeform= HTTP/1.1
> Host: httpbin:8000
> User-Agent: curl/7.80.0-DEV
> accept: application/json
> Traceparent: 00-7543d15e09e5d61801d4f74cde1269b8-604ef051d35c5b3f-01
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< server: envoy
< date: Wed, 10 Nov 2021 20:36:04 GMT
< content-type: application/json
< content-length: 1032
< access-control-allow-origin: *
< access-control-allow-credentials: true
< x-envoy-upstream-service-time: 5
<
{
  "args": {
    "freeform": ""
  },
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Grpc-Trace-Bin": "AAB1Q9FeCeXWGAHU90zeEmm4AaDHmGRtdM7wAgE",
    "Host": "httpbin:8000",
    "Traceparent": "00-7543d15e09e5d61801d4f74cde1269b8-a0c798646d74cef0-01",
    "User-Agent": "curl/7.80.0-DEV",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "a0c798646d74cef0",
    "X-B3-Traceid": "7543d15e09e5d61801d4f74cde1269b8",
    "X-Cloud-Trace-Context": "7543d15e09e5d61801d4f74cde1269b8/11585396123534413552;o=1",
    "X-Envoy-Attempt-Count": "1",
    "X-Forwarded-Client-Cert": "<REDACTED>"
  },
  "json": null,
  "method": "GET",
  "origin": "127.0.0.6",
  "url": "http://httpbin:8000/anything?freeform="
}

Ten en cuenta que en el conjunto de encabezados de solicitud que se muestra, el conjunto completo de encabezados de contexto de seguimiento está presente.

Para ver más ejemplos que propagan los encabezados, consulta Propagación del contexto de seguimiento.

Crea un seguimiento desde un cliente con un ID personalizado

Si deseas crear un seguimiento a partir de un cliente con un ID personalizado, usa el comando curl para crear una solicitud con un cliente externo y forzarlo a mostrar un seguimiento. Por ejemplo:

curl $URL --header "x-client-trace-id: 105445aa7843bc8bf206b12000100000"

Para obtener más información sobre x-client-trace-id, consulta la documentación de Envoy.

Salida mediante puertas de enlace de salida

Recomendamos que instales una puerta de enlace insertada, como se describe en Instala y actualiza puertas de enlace.

Interfaz de red de contenedor de Istio

La forma de habilitar la interfaz de red de contenedor (CNI) de Istio depende del entorno en el que esté instalado Anthos Service Mesh.

  1. Habilita una política de red.

  2. Elige el archivo de superposición que coincida con tu plataforma.

Habilita CNI en GKE

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /home/kubernetes/bin
      excludeNamespaces:
        - istio-system
        - kube-system

Habilita la CNI en un entorno local

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    cni:
      enabled: true
      namespace: kube-system
  values:
    cni:
      cniBinDir: /opt/cni/bin
      excludeNamespaces:
        - istio-system
        - kube-system
        - gke-system

Habilita la observabilidad de Google Cloud para servicios fuera de Google Cloud

Si instalas Anthos Service Mesh con la CA de Istio fuera de Google Cloud, se informan las métricas a Prometheus de forma predeterminada. Usa esta opción para habilitar las métricas de informes en la observabilidad de Google Cloud, o para Prometheus y Stackdriver, de modo que puedas usar los paneles de Anthos Service Mesh.

Solo Stackdriver

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: false
        stackdriver:
          enabled: true

Stackdriver y Prometheus

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    telemetry:
      enabled: true
      v2:
        enabled: true
        prometheus:
          enabled: true
        stackdriver:
          enabled: true

Habilita un balanceador de cargas interno

Recomendamos que instales una puerta de enlace inyectada como se describe en Instala y actualiza puertas de enlace para configurar un balanceador de cargas interno en GKE. Cuando configuras el servicio de puerta de enlace, debes incluir la anotación: networking.gke.io/load-balancer-type: "Internal"

Administración de certificados externos en la puerta de enlace de entrada

Para obtener información sobre cómo habilitar la administración de certificados externos en la puerta de enlace de entrada mediante SDS de Envoy, consulta Protege las puertas de enlace.