[Cloud native | Aprendiendo istio desde cero] 3. Explicación detallada de los componentes de istio

inserte la descripción de la imagen aquí

Explicación detallada de los componentes de istio

Hay muchos componentes de servicio de Istio. A partir del proceso anterior, básicamente puede ver cómo coopera cada componente. El propósito específico y la función de cada componente se explican a continuación.

[root@k8smaster ~]# kubectl get svc -n istio-system | awk '{print $1}' 
istio-egressgateway 
istio-ingressgateway 
istiod

Piloto

Pilot es el principal componente de control de Istio, que emite comandos para controlar al cliente. En todo el sistema, Pilot realiza las siguientes tareas:

1. Obtenga información del servicio del registro de Kubernetes u otras plataformas para completar el proceso de descubrimiento del servicio.

2. Lea las diversas configuraciones de control de Istio y, después de la conversión, envíelas al plano de datos para su implementación.

inserte la descripción de la imagen aquí

Pilot envía el contenido de configuración a Envoy en el plano de datos, y Envoy convierte la información de definición, como el enrutamiento, el servicio, el monitoreo y la agrupación en una configuración local de acuerdo con las instrucciones de Pilot, y completa la implementación del comportamiento de control.

1) Pilot proporciona detección de servicios para Envoy

2) Proporcionar funciones de gestión de tráfico (p. ej., pruebas A/B, lanzamientos canary, etc.) y funciones de resiliencia (tiempos de espera, reintentos, disyuntores, etc.);

3) Generar configuración de enviado

4) Enviar enviado

5) Supervisar y administrar el estado de ejecución de Envoy, como que el agente piloto sea responsable de reiniciar Envoy cuando falla, o recargar Envoy después de cambios en la configuración de Envoy.

Enviado

¿Qué es Envoy?

Envoy es un proxy de alto rendimiento desarrollado en C++ que coordina el tráfico entrante y saliente para todos los servicios en una red de servicios.

Envoy tiene muchas características poderosas como:

Descubrimiento de servicios dinámicos

balanceo de carga

terminación TLS

Proxy HTTP/2 y gRPC

interruptor automático

Examen de salud

división de tráfico

lanzamiento en escala de grises

inyección de falla

¿Cuál es la relación entre Envoy y los servicios en Istio?

Envoy y el Servicio A pertenecen al mismo Pod y comparten la red y el espacio de nombres. Envoy procesa el tráfico que entra y sale del Pod A y actúa en el Servicio A de acuerdo con las reglas de las solicitudes externas.

¿Qué es Piloto-agente?

Envoy no interactúa directamente con k8s. El proceso Pilot-agent administrado por pilot-agent genera el archivo de configuración de Envoy de acuerdo con la información de configuración en el servidor API de K8S y es responsable de iniciar el proceso de Envoy.
Envoy es iniciado por el proceso Pilot-agent. Después del inicio, Envoy lee el archivo de configuración generado por Pilot-agent para él, y luego obtiene la dirección de Pilot de acuerdo con la configuración del archivo, y extrae la información de configuración dinámica de el piloto a través del plano de datos, incluido el enrutamiento (ruta), el oyente (oyente), el clúster de servicio (clúster) y el punto final de servicio (punto final).

Ciudadela

Responsable de manejar la comunicación TLS entre diferentes servicios en el sistema. Citadel actúa como una autoridad certificadora (CA) y genera certificados para permitir la comunicación mTLS segura en el plano de datos.

Citadel es el componente central de seguridad de Istio y proporciona generación, distribución, rotación y revocación automáticas de claves y certificados. Citadel ha estado monitoreando Kube-apiserver, generando claves de certificado para cada servicio en forma de Secreto y montando un volumen en el Pod cuando se crea el Pod. El contenedor proxy usa estos archivos para la autenticación de identidad del servicio y luego actúa como proxy en ambos extremos. El servicio implementa funciones de seguridad como la autenticación TLS mutua, el cifrado de canales y la autorización de acceso. Como se muestra en la figura, el servicio frontend usa HTTP para acceder al servicio de pronóstico, y la función de autenticación se puede agregar al servicio a través de la configuración.Los Envoys en ambos lados establecerán un canal TLS para la autenticación mutua, lo que habilitará HTTPS para la autenticación mutua. entre servicios.

inserte la descripción de la imagen aquí

Galera

Galley es el componente de validación, extracción, procesamiento y distribución de la configuración de istio. Galley es un servicio que proporciona gestión de configuración. El principio de implementación es verificar la configuración a través del ValidatingWebhook proporcionado por k8s.

Galley permite que Istio funcione con otros entornos además de Kubernetes porque puede convertir datos de configuración dispares en un formato común que Istio entiende.

Puerta de entrada

Ingressgateway es la puerta de enlace en la entrada, y el acceso a los servicios en la red desde fuera de la red se realiza a través de esta puerta de enlace. istio-ingressgateway es un servicio de tipo Loadbalancer. A diferencia de otros componentes del servicio, que solo tienen uno o dos puertos, istio-ingressgateway abre un conjunto de puertos, que son los puertos de acceso externo para los servicios en la red. Como se muestra en la figura a continuación, la carga del gateway de entrada de la red istio-ingressgateway es el mismo proceso de ejecución que el de los sidecars de la red.También recibe las reglas de tráfico del piloto y las ejecuta como otros sidecars de la red.

Sidecar-inyector

Sidecar-injector es el componente responsable de la inyección automática. Siempre que la inyección automática esté habilitada, se llamará automáticamente a istio-sidecar-injector para inyectar el contenedor Sidecar en el Pod cuando se cree el Pod.
En el entorno de Kubernetes, según la configuración de inyección automática, cuando Kube-apiserver intercepta la solicitud creada por el Pod, llamará al servicio de inyección automática istio-sidecar-injector para generar la descripción del contenedor sidecar e insertarlo en la definición. del Pod original. El Pod creado incluye no solo el contenedor comercial, sino también el contenedor Sidecar. Este proceso de inyección es transparente para el usuario.

otros componentes

Además de los propios componentes de Istio con el prefijo "istio", Jaeger-agent, Jaeger-collector, Jaeger-query, Kiali, Prometheus, Grafana, Tracing, Zipkin y otros componentes generalmente se instalan en el clúster. Estos componentes proporcionan a Istio Calls Chain, monitoreo y otras funciones, puede optar por instalar para completar las funciones completas de monitoreo y administración del servicio.

escribir al final

No es fácil de crear, si crees que el contenido es útil para ti, ¡por favor dame un seguimiento de tres enlaces para apoyarme! Si hay algún error, indíquelo en los comentarios y lo cambiaré a tiempo.

Serie en proceso de actualización: Aprendiendo istio desde cero

Gracias por mirar, el artículo se mezcla con la comprensión personal, si hay algún error, comuníquese conmigo para señalarlo ~

Supongo que te gusta

Origin blog.csdn.net/qq_45400861/article/details/127480728
Recomendado
Clasificación