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,namespaceyservice account. Tiene un formato de identidad SPIFFE despiffe://<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
- actualización Canary
- Consulta la actualización basada en la revisión.
- 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. Anthos Service Mesh consiste en el plano de control administrado por Google y el plano de datos opcional administrado por Google, que se encuentra en vista previa.
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. Anthos Service Mesh administrado ofrece un plano de datos administrado por Google que está en vista previa.
E
- Puerta de enlace de salida
- Una puerta de enlace de salida es un proxy de Envoy que te permite configurar un nodo de salida dedicado para el tráfico que sale de la malla. Usa el recurso personalizado de puerta de enlace para configurar el proxy. Una puerta de enlace de salida te permite limitar qué servicios pueden o deben acceder a redes externas. Consulta Instala y actualiza puertas de enlace para obtener más información.
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.
H
- Manifiestos hidratados
- Es un manifiesto que está listo para su implementación en el destino. Para hidratar un manifiesto, por lo general, debes usar una herramienta como Helm, Kustomize o
kpta fin de establecer valores para las variables del manifiesto.
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
Es una puerta de enlace de entrada es un proxy de Envoy que funciona como un balanceador de cargas para manejar el tráfico entrante que entra desde fuera de la malla. Usa el recurso personalizado de la puerta de enlace para configurar el balanceador de cargas, crear 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. Consulta Instala y actualiza puertas de enlace para obtener más información.
- Inyección
Es la inserción o inserción automática se refiere al uso de los webhooks de mutación para modificar las especificaciones del pod en el momento de la creación. Usa la inserción a fin de agregar la configuración del sidecar del proxy de Envoy para los servicios de la malla o configurar el proxy de Envoy de las puertas de enlace.
- actualización in situ
Es una actualización in situ reemplaza el plano de control existente por una nueva revisión. Recomendamos actualizaciones basadas en la revisión.
istiodistiod (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.
IstioOperatorUn 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).
Manifiesto
Un objeto de configuración de Kubernetes que se usa para crear, modificar y borrar recursos de Kubernetes como pods, implementaciones, servicios o recursos Ingress En la documentación de Anthos Service Mesh, el manifiesto que usas para configurar el plano de control se conoce como archivo superpuesto.
Los manifiestos existen en uno de dos estados: renderizados (también denominados hidratados) o no renderizados. Un manifiesto no renderizado no está listo para su implementación en un destino. El proceso de renderización, que incluye propagar valores específicos en el manifiesto, a menudo se realiza mediante herramientas como Helm, Kustomize y kpt.
- CA de Mesh
- El nombre de la autoridad certificadora administrada por Google que administra certificados de mTLS. La CA de Mesh está habilitada de forma predeterminada cuando instalas Anthos Service Mesh en clústeres de GKE en Google Cloud, y puedes habilitar la CA de Mesh de forma opcional cuando instalas Anthos Service Mesh 1.10 o una versión posterior en GKE en VMware o Bare Metal.
- 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 aistioctl installo a la secuencia de comandosinstall_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 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 substringmytrustdomain.comespecifica que la carga de trabajo proviene de un dominio de confianza llamadomytrustdomain.comCuando 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.