Glosario

En esta página, se proporcionan definiciones breves y vínculos para obtener más información sobre términos que se usaron en la documentación de Anthos Service Mesh.

C

plano de control

Un plano de control es un conjunto de servicios del sistema que configuran la malla o un subconjunto de la malla para administrar la comunicación entre las instancias de carga de trabajo en el interior. Anthos Service Mesh 1.9 y versiones posteriores proporciona dos planos de control:

Plano de control administrado por Google (Vista previa): Este es un servicio de Google Cloud completamente administrado que solo necesitas configurar, mientras que Google se encarga de su confiabilidad, actualizaciones, escalamiento y seguridad por ti.
Plano de control en el clúster: Esta es una distribución de istiod con asistencia de Google que instalas en tu clúster. Cuando instalas Anthos Service Mesh con istiod, eres responsable de actualizar y configurar la seguridad y el escalamiento.

Aunque el plano de control distribuye su configuración a los proxies de sidecar, el plano de control no participa directamente en el control del tráfico de las cargas de trabajo en la malla.

D

plano de datos: El plano de datos es la parte de la malla que administra directamente la comunicación entre las instancias de carga de trabajo. El plano de datos de Anthos Service Mesh usa proxies implementados como sidecars para mediar y controlar todo el tráfico de TCP que envían y reciben tus servicios de malla.

F

flota: Una flota (antes conocida como entorno) te permite organizar clústeres para facilitar la administración de varios clústeres. Registrar tus clústeres en una flota simplifica la administración de una malla de varios clústeres, ya que introduce el concepto de “similitud” para la identidad, los espacios de nombres y los servicios. Si tienes clústeres en diferentes proyectos, deberás registrarlos con el proyecto host de flota en lugar de hacerlo con el proyecto en el que se creó el clúster. Para obtener más información sobre las flotas, consulta Presentación de las flotas.

I

identidad

La identidad es un concepto fundamental de la infraestructura de seguridad. El modelo de identidad de Anthos Service Mesh se basa en una identidad de carga de trabajo de primera clase. Al comienzo de la comunicación servicio a servicio, las dos partes intercambian credenciales con su información de identidad para fines de autenticación mutua.

Los clientes verifican la identidad del servidor con su información de nombres seguros a fin de determinar si el servidor tiene autorización para ejecutar el servicio.

Los servidores verifican la identidad del cliente para determinar a qué información puede acceder el cliente. Los servidores deciden si deben permitir el acceso en función de las políticas de autorización configuradas.

Mediante el uso de la identidad, los servidores pueden auditar la hora a la que se accedió a la información y la información a la que accedió un cliente específico. También pueden cobrar a los clientes según los servicios que usen y rechazar el acceso a los servicios a los clientes que no pagaron su facturación.

El modelo de identidad de Anthos Service Mesh es lo suficientemente flexible y detallado como para representar a un usuario humano, un servicio individual o un grupo de servicios. En plataformas sin identidad de servicio de primer nivel, Anthos Service Mesh puede usar otras identidades que pueden agrupar instancias de servicio, como los nombres de servicio.

Anthos Service Mesh admite las siguientes identidades de servicio en diferentes plataformas:

Kubernetes: Cuenta de servicio de Kubernetes
Google Kubernetes Engine: Cuenta de servicio de Google Cloud
Google Cloud: Cuenta de servicio de Google Cloud

istiod

Istiod es el objeto binario monolítico consolidado que proporciona servicios de plano de control. Antes de Anthos Service Mesh 1.5, los servicios del plano de control fueron proporcionados por componentes separados llamados Pilot, Citadel, Mixer y Gally.

IstioOperator

Un recurso personalizado que uses para configurar el plano de control. Para obtener más información, consulta IstioOperator en los documentos de Istio.

millones

TLS mutua: Anthos Service Mesh usa TLS mutua (mTLS) para la autenticación y encriptación entre los servicios de la malla. mTLS permite que las cargas de trabajo verifiquen las identidades de las demás y se autentiquen entre sí. Es posible que estés familiarizado con la TLS simple por su uso en HTTPS para permitir que los navegadores confíen en los servidores web y encripten los datos que se intercambian. Cuando se usa la TLS simple, el cliente establece que el servidor es de confianza mediante la validación de su certificado. La mTLS es una implementación de la TLS en la que el cliente y el servidor se presentan certificados y verifican sus identidades entre sí.

N

network: Anthos Service Mesh usa una definición simplificada de la red basada en la conectividad general. Las instancias de carga de trabajo están en la misma red si pueden comunicarse de forma directa, sin una puerta de enlace.

archivo de superposición: Un archivo YAML que contiene un recurso personalizado IstioOperator (CR). Usa archivos de superposición para configurar el plano de control. Puedes anular la configuración predeterminada del plano de control y habilitar las características opcionales compatibles en un archivo YAML que pasas a istioctl install o a la secuencia de comandos install_asm. Puedes agregar capas a más superposiciones, y cada archivo superpuesto anula la configuración de las capas anteriores. Consulta Habilita funciones opcionales para el YAML que puedes usar a fin de habilitar características que no están habilitadas de forma predeterminada.

P

clúster principal: Un clúster principal es un clúster con un plano de control. Una malla única puede tener más de un clúster principal para alta disponibilidad o reducir la latencia. En la documentación de Istio 1.7, una implementación de varias instancias se conoce como un plano de control replicado.

R

clúster remoto: Un clúster remoto es un clúster que se conecta a un plano de control que reside fuera del clúster. Un clúster remoto puede conectarse a un plano de control que se ejecuta en un clúster principal o en un plano de control externo.
Revisión: Una revisión representa una instantánea de tiempo de la versión y la configuración de código de la aplicación. Cuando instalas o actualizas Anthos Service Mesh, se agrega una etiqueta de revisión a istiod para identificar la versión. Para habilitar la inserción automática del sidecar, debes agregar la etiqueta de revisión a tus espacios de nombres y reiniciar tus Pods. Usa la etiqueta de revisión para asociar los Pods en un espacio de nombres con una revisión istiod en particular, de modo que puedas actualizar de forma segura a un nuevo plano de control y revertir a la revisión original en caso de que ocurran problemas.

S

nombres seguros: Las identidades de servidor están codificadas en certificados, pero los nombres de servicio se recuperan a través del servicio de descubrimiento o DNS. La información de nombres seguros asigna las identidades del servidor a los nombres de servicio. La asignación de la identidad A al nombre de servicio B significa que “A tiene autorización para ejecutar el servicio B”. El plano de control observa el apiserver, genera las asignaciones de nombres seguros y las distribuye de forma segura a los proxies de sidecar.
malla de servicios: Una malla de servicios o una malla es una capa de infraestructura que permite una comunicación administrada, observable y segura entre instancias de carga de trabajo.
sidecar: Un patrón para ejecutar una utilidad o un asistente junto con una carga de trabajo. Si usas Kubernetes, los sidecars se ejecutarán junto con el contenedor de carga de trabajo en un Pod. Cuando se trata de la malla de servicios, la palabra “sidecar” suele usarse para hacer referencia al proxy.

T

dominio de confianza

El dominio de confianza corresponde a la raíz de confianza de un sistema y forma parte de una identidad de carga de trabajo.

Anthos Service Mesh usa un dominio de confianza para crear todas las identidades dentro de una malla. Por ejemplo, en el ID de SPIFFE spiffe://mytrustdomain.com/ns/default/sa/myname, la substring mytrustdomain.com especifica que la carga de trabajo proviene de un dominio de confianza llamado mytrustdomain.com

Cuando se usa la CA de Mesh, Anthos Service Mesh genera automáticamente el dominio de confianza. Se basa en el grupo de cargas de trabajo del clúster, con el formato de project-id.svc.id.goog o project-id.hub.id.goog.

Puedes tener uno o más dominios de confianza en una malla de varios clústeres, siempre que los clústeres compartan la misma raíz de confianza.

W

carga de trabajo: Una carga de trabajo puede ser una aplicación, un servicio o algún otro programa que se aloja en contenedores, como un trabajo por lotes o un daemon que se ejecuta en una plataforma. La plataforma puede ser un clúster de Kubernetes, una máquina virtual o algún otro entorno, como Google Distributed Cloud Virtual for Bare Metal. Las cargas de trabajo tienen nombres, ID únicos y espacios de nombres. En Kubernetes, una carga de trabajo generalmente corresponde a una implementación, pero hay otros tipos de cargas de trabajo, como una StatefulSet.