Habilita funciones opcionales en un plano de control en el 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 el clúster, las funciones que están habilitadas de forma predeterminada difieren según la plataforma. Puedes anular la configuración predeterminada y habilitar una función opcional; para ello, haz lo siguiente: que incluye un archivo de superposición cuando instalas (o actualizas) Cloud Service Mesh. Un archivo de superposición es un archivo YAML que contiene un recurso personalizado (CR) IstioOperator que usas para configurar el plano de control. Especifica una función por archivo de superposición. Puedes superponer más superposiciones y cada archivo de superposición anula la configuración en las capas anteriores.

Precaución: El uso de asmcli install reemplaza el plano de control existente. configuración. Cuando habilitas funciones opcionales en una instalación existente, asegúrate de especificar todos los archivos que quieres conservar en el original de la aplicación, así como los archivos de superposición para las funciones que deseas habilitar. Recomendamos que almacenes los archivos de superposición que uses para instalación en el control de código fuente para que puedas aplicar los mismos parámetros de configuración a tu plano de control con actualizaciones o cuando habilites funciones opcionales adicionales. Esto garantiza que no haya tiempo de inactividad cuando se habiliten las 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 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 Cloud Service Mesh con la secuencia de comandos asmcli, puedes especificar uno o más archivos de superposición con las opciones --option o --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 hacer cambios en el archivo de superposición y, luego, usa la opción --custom_overlay para y pasarla a asmcli.

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

No incluyas varios CR en un archivo superpuesto	Crea archivos superpuestos 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 el 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 que se requiere para las funciones predeterminadas y, luego, los archivos de superposición.

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. Asegúrate de omitir la extensión .yaml y de incluir solo el nombre del archivo de superposición, como iap-operator y attached-cluster. Para ver una lista de opciones, consulta el 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 Cloud 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 ejecutas un comando curl, 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: unable to start container process: exec: "curl": executable file not found in $PATH: unknown

Si ejecutas un comando de 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 Cloud Service Mesh desde un registro de contenedores personalizado. Por ejemplo:

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

La siguiente es una lista de imágenes de la malla de servicios de Cloud que debes duplicar Container Registry personalizado:

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

Nota: Si usas un servicio canónico, también debes duplicar 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.

Agrega imágenes a un registro privado

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

Nota: Usa un cliente desde el cual puedas extraer de gcr.io y enviar al registro privado.

1. Extrae las imágenes de la malla de servicios de Cloud:

   docker pull gke.gcr.io/asm/install-cni:1.23.2-asm.2
   docker pull gke.gcr.io/asm/mdp:1.23.2-asm.2
   docker pull gke.gcr.io/asm/pilot:1.23.2-asm.2
   docker pull gke.gcr.io/asm/proxyv2:1.23.2-asm.2
   

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

   export PRIVATE_REGISTRY_URL=PRIVATE_REGISTRY_URL
   

   Reemplaza 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.23.2-asm.2 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/install-cni:1.23.2-asm.2
   docker tag gke.gcr.io/asm/mdp:1.23.2-asm.2 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/mdp:1.23.2-asm.2
   docker tag gke.gcr.io/asm/pilot:1.23.2-asm.2 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/pilot:1.23.2-asm.2
   docker tag gke.gcr.io/asm/proxyv2:1.23.2-asm.2 \
    ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/proxyv2:1.23.2-asm.2
   

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

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

5. (Opcional) Si usas un servicio canónico y, luego, agrega el imágenes canónicos del servicio a tu registro privado.
   1. Extrae las imágenes de servicio canónicas de la malla de servicios de Cloud:

              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 al registro privado:

              docker push ${PRIVATE_REGISTRY_URL}/gke.gcr.io/asm/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 desde el registro privado, el procedimiento se realizó correctamente.

Aumenta la duración del drenaje de finalización

De forma predeterminada, Envoy esperará cinco segundos (5s) para que se completen las conexiones existentes cuando se cierre un pod.

El terminationGracePeriodSeconds del Pod 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 los registros de acceso

---
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 la malla de servicios de Cloud en las siguientes ubicaciones: plataformas:

• GKE en Google Cloud
• Clústeres de GKE Enterprise locales si instalas con la autoridad certificadora 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 Cómo acceder a los seguimientos.

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 del contenedor (CNI) de Istio depende de el entorno en el que está instalado Cloud 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 los registros de tráfico para fuera de Google Cloud

Si instalas Cloud Service Mesh con la AC de Istio fuera de Google Cloud, se informan las métricas a Prometheus de forma predeterminada. Utiliza esta opción para habilitar los informes de tráfico en su lugar, o en Prometheus y Stackdriver, por lo que puedes usar Paneles 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

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.