Habilitar funciones opcionales en un plano de control en clúster

En esta página se describe cómo habilitar funciones opcionales en Cloud Service Mesh con un plano de control en el clúster.

Cuando instalas Cloud Service Mesh en clústeres, las funciones que están habilitadas de forma predeterminada varían según la plataforma. Puedes anular la configuración predeterminada y habilitar una función opcional incluyendo un archivo overlay al instalar (o actualizar) Cloud Service Mesh. Un archivo de superposición es un archivo YAML que contiene un recurso personalizado (CR) de IstioOperator que se usa para configurar el plano de control. Especifica una función por archivo de superposición. Puedes añadir más superposiciones y cada archivo de superposición anula la configuración de las capas anteriores.

Precaución: Si usas asmcli install, se sobrescribirá la configuración del plano de control. Cuando habilites funciones opcionales en una instalación, asegúrate de especificar todos los archivos que quieras conservar en la configuración original, así como los archivos de superposición de las funciones que quieras habilitar. Te recomendamos que almacenes los archivos de superposición que utilices para la instalación en el control de versiones, de forma que puedas aplicar las mismas configuraciones a tu plano de control con las actualizaciones o al habilitar funciones opcionales adicionales. De esta forma, no habrá tiempo de inactividad al habilitar funciones opcionales.

Acerca de los archivos de superposición

Los archivos de superposición de esta página se encuentran en el paquete anthos-service-mesh de GitHub. Estos archivos contienen personalizaciones comunes de la configuración predeterminada. Puede usar estos archivos tal cual o hacer los cambios que necesite.

Cuando instalas Cloud Service Mesh con la secuencia de comandos asmcli, puedes especificar uno o varios archivos de superposición con las opciones --option o --custom_overlay. Si no necesitas hacer ningún cambio en los archivos del repositorio anthos-service-mesh, puedes usar --option y la secuencia de comandos obtendrá el archivo de GitHub por ti. De lo contrario, puedes hacer cambios en el archivo de superposición y, a continuación, usar la opción --custom_overlay para pasarlo a asmcli.

Importante: No especifiques más de un IstioOperator CR en un archivo de superposición, ya que istioctl install solo aplica el primer CR que encuentra en el archivo.

No incluyas varios CRs en un archivo de superposición	Crear archivos de superposición independientes para cada CR

Cómo habilitar funciones opcionales

Los siguientes ejemplos se han simplificado para mostrar solo el uso de las superposiciones personalizadas para habilitar funciones opcionales. Sustituye OTHER_FLAGS por las marcas de instalación obligatorias.

Importante: El orden de los archivos en la línea de comandos es importante. Asegúrate de especificar primero la configuración necesaria para las funciones predeterminadas y, después, los archivos de superposición.

El comando asmcli install ofrece dos formas de habilitar una función opcional. El método que utilices dependerá de si necesitas hacer cambios en el archivo de superposición.

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

  ./asmcli install \
    OTHER_FLAGS \
    --option OPTION_NAME
  

  Sustituye OPTION_NAME por la opción que quieras habilitar. No incluyas la extensión .yaml y solo incluye el nombre del archivo de superposición, como iap-operator y attached-cluster. Para ver 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
  

  Sustituye PATH_TO_FILE por la ruta al archivo de superposición que quieras usar.

YAML de funciones opcionales

En las siguientes secciones se proporciona el código YAML para habilitar las funciones opcionales y compatibles.

Modo STRICT de mTLS

La configuración de global.mtls.enabled se ha quitado del IstioOperator CR para evitar problemas con las actualizaciones y ofrecer una instalación más flexible. Para habilitar STRICT mTLS, configura una política de autenticación entre pares.

Imagen de proxy sin distribución

Como práctica recomendada, debes restringir el contenido de un tiempo de ejecución de contenedor a los paquetes necesarios. Este enfoque mejora la seguridad y la relación señal/ruido de los escáneres de vulnerabilidades y exposiciones comunes (CVE). Istio proporciona imágenes de proxy basadas en imágenes base sin distribución.

La siguiente configuración habilita las imágenes sin distribución para toda la malla de servicios de Cloud. Para que se aplique un cambio de tipo de imagen, es necesario reiniciar cada pod y volver a insertarlo.

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

La imagen sin distribución no contiene ningún archivo binario que no sea el proxy. Por lo tanto, no es posible exec una shell ni usar curl, ping u otras utilidades de depuración dentro del contenedor.

Si ejecutas un comando curl, aparece 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: unable to start container process: exec: "curl": executable file not found in $PATH: unknown

Si ejecutas un comando de shell, aparece 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 acceder a estas herramientas para pods específicos, puedes anular imageType mediante la siguiente anotación de pod.

sidecar.istio.io/proxyImageType: debug

Después de cambiar el tipo de imagen de un despliegue mediante la anotación, se debe reiniciar el despliegue.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

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

Usar una superposición personalizada para un registro personalizado

Puedes usar una superposición personalizada para registros personalizados, por ejemplo, si necesitas instalar Cloud 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 Cloud Service Mesh que debes replicar en el registro de contenedores personalizado:

• Install-cni - gke.gcr.io/asm/install-cni:1.25.3-asm.11
• Plano de datos gestionado: gke.gcr.io/asm/mdp:1.25.3-asm.11
• Piloto - gke.gcr.io/asm/pilot:1.25.3-asm.11
• Proxyv2 - gke.gcr.io/asm/proxyv2:1.25.3-asm.11

Nota: Si usas un servicio canónico, también debes replicar los registros de contenedores personalizados gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1 y gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16.

Añadir imágenes a un registro privado

Para enviar imágenes de Cloud Service Mesh a un registro privado, sigue estos pasos.

Nota: Usa un cliente desde el que puedas extraer datos de gcr.io e insertarlos en tu registro privado.

1. Extrae las imágenes de Cloud Service Mesh:

   docker pull gke.gcr.io/asm/install-cni:1.25.3-asm.11
   docker pull gke.gcr.io/asm/mdp:1.25.3-asm.11
   docker pull gke.gcr.io/asm/pilot:1.25.3-asm.11
   docker pull gke.gcr.io/asm/proxyv2:1.25.3-asm.11
   

2. Crea una variable para la URL de tu registro privado:

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Sustituye PRIVATE_REGISTRY_URL por la URL de tu registro privado.
3. Etiqueta las imágenes con la URL de tu registro privado:

   docker tag gke.gcr.io/asm/install-cni:1.25.3-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.25.3-asm.11
   docker tag gke.gcr.io/asm/mdp:1.25.3-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.25.3-asm.11
   docker tag gke.gcr.io/asm/pilot:1.25.3-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.25.3-asm.11
   docker tag gke.gcr.io/asm/proxyv2:1.25.3-asm.11 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.25.3-asm.11
   

4. Envía las imágenes etiquetadas a tu registro privado:

   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.25.3-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.25.3-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.25.3-asm.11
   docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.25.3-asm.11
   

5. (Opcional) Si usas un servicio canónico, añade las imágenes del servicio canónico a tu registro privado.
   1. Extrae las imágenes de servicio canónico de Cloud Service Mesh:

              docker pull gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker pull gke.gcr.io/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.13.1 \
              ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker tag gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16 \
              ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

   3. Envía las imágenes etiquetadas a tu registro privado:

              docker push ${PRIVATE_REGISTRY_URL}/gcr.io/kubebuilder/kube-rbac-proxy:v0.13.1
              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/canonical-service-controller:1.10.3-asm.16
              

Si puedes extraer las imágenes etiquetadas de tu registro privado, el procedimiento se habrá completado correctamente.

Aumentar la duración del drenaje de la finalización

De forma predeterminada, Envoy esperará cinco segundos (5s) a que se completen las conexiones ya establecidas cuando un pod esté finalizando.

El pod terminationGracePeriodSeconds debe ser mayor que el valor terminationDrainDuration.

Para obtener más información, consulta Opciones de malla global.

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      terminationDrainDuration: 30s

Habilitar registros de acceso

---
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.

Cloud Trace

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

• GKE en Google Cloud
• Clústeres de GKE Enterprise on-premise si instalas la autoridad de certificación de Cloud Service Mesh

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

Para obtener más información, consulta Acceder a los rastreos.

Salida a través de pasarelas de salida

Te recomendamos que instales una pasarela insertada tal como se describe en Instalar y actualizar pasarelas. La inyección, o inyección automática, hace referencia al uso de webhooks mutables para modificar las especificaciones de los pods en el momento de la creación. Utilizas la inyección para añadir la configuración del sidecar del proxy de Envoy a tus servicios de malla o para configurar el proxy de Envoy de las pasarelas.

Interfaz de red de contenedores de Istio

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

1. Habilita una política de red.

2. Elige el archivo de superposición que corresponda a tu plataforma.

Habilitar 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

Habilitar CNI on-premise

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

Habilitar los registros de tráfico paraGoogle Cloud

Al instalar Cloud Service Mesh con Istio CA fuera de Google Cloud , se envían métricas a Prometheus de forma predeterminada. Usa esta opción para habilitar los informes de registros de tráfico o para habilitar tanto Prometheus como Stackdriver, de forma que puedas usar los paneles de control de Cloud 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

Habilitar un balanceador de carga interno

Te recomendamos que instales una pasarela insertada tal como se describe en Instalar y actualizar pasarelas para configurar un balanceador de carga interno en GKE. Al configurar el servicio de pasarela, incluye la anotación: networking.gke.io/load-balancer-type: "Internal"

Gestión de certificados externos en la pasarela de entrada

Para obtener información sobre cómo habilitar la gestión de certificados externos en el gateway de entrada mediante Envoy SDS, consulta Secure Gateways (Gateways seguros).