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.

A

Workload Identity de Anthos
una tuple de trust domain, namespace y service account. Tiene un formato de identidad SPIFFE de spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> en los certificados x509 de la carga de trabajo de Anthos. Para otros tipos de credenciales (p.ej., tokens de OIDC), el formato puede variar.

C

Servicio canónico
Una etiqueta aplicada a las cargas de trabajo en Anthos Service Mesh que te permite agrupar una o más cargas de trabajo como un servicio lógico dentro de la malla de servicios. Una carga de trabajo pertenece exactamente a un servicio canónico, mientras que puede pertenecer a varios servicios de Kubernetes. Un servicio canónico se identifica mediante un nombre y un espacio de nombres, y se puede dividir aún más en una o más revisiones canónicas.
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: 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

Puerta de enlace de entrada

Una puerta de enlace de entrada representa un balanceador de cargas para manejar el tráfico entrante que ingresa desde fuera de la malla. Utiliza los recursos de la puerta de enlace de Istio para configurar el balanceador de cargas y crea servicios virtuales y políticas de autenticación a fin de controlar cómo se protege y enruta el tráfico entrante a las cargas de trabajo.

istiod

istiod (la "d" es por "daemon") 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 usas para configurar el plano de control en el clúster. Para obtener más información, consulta Habilita funciones opcionales.

millones

Grupo de instancias administrado (MIG)
Te permite operar aplicaciones en varias VM idénticas, a partir de un tamaño de MIG mínimo de una VM. Puedes hacer que tus cargas de trabajo sean escalables y tengan alta disponibilidad gracias a los servicios de MIG automatizados, que incluyen el ajuste de escala automático, la reparación automática, la implementación regional (en varias zonas) y la actualización automática. Para obtener más información, consulta Grupos de instancias administrados (MIG).
CA de Mesh
El nombre de la autoridad certificadora administrada por Google que administra certificados de mTLS. La CA de Mesh se instala de forma predeterminada cuando instalas Anthos Service Mesh.
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.

O

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, ocurre lo siguiente: la etiqueta de revisión se agrega al plano de control. 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. La etiqueta de revisión asocia los pods en un espacio de nombres con una revisión del plano de control particular.
actualización basada en revisiones
Las migraciones de OSS Istio y las actualizaciones siguen el proceso de actualización basado en la revisión (denominado “actualizaciones canary” en la documentación de Istio). Con una actualización basada en revisiones, la versión nueva del plano de control se instala junto con el plano de control existente. Luego, transfiere algunas de tus cargas de trabajo a la revisión nueva, lo que te permite supervisar el efecto de la actualización con un pequeño porcentaje de las cargas de trabajo antes de migrar todo el tráfico a la revisión nueva.

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.

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.
WorkloadEntry
te permite describir extremos de Pod que no son de Kubernetes que deben ser parte de la malla y tratarlos de la misma manera que un Pod de Kubernetes. En nuestro caso, cada VM está registrada como una WorkloadEntry en la malla. Para obtener más información, consulta https://istio.io/latest/blog/2020/workload-entry/
WorkloadGroup
describe una colección de instancias de carga de trabajo. Consulta WorkloadGroup.
Grupo de Workload Identity
El límite de confianza, también conocido como un dominio de confianza de Anthos Service Mesh.