Active Oracle Cloud Infrastructure Service Mesh en sus aplicaciones de Kubernetes
Los clientes de Oracle Cloud Infrastructure (OCI) se han movido cada vez más hacia una arquitectura de microservicios que, junto con sus beneficios, también trae nuevos desafíos. En una arquitectura de microservicios, las aplicaciones monolíticas se dividen en microservicios más pequeños que se comunican a través de la red mediante una API. Esto provoca un aumento del tráfico de red y aumenta la complejidad y la superficie de ataque general en la arquitectura.
- Permite controlar el flujo de tráfico de microservicios.
- Proporciona visibilidad de las aplicaciones.
- Permite a los microservicios conectarse de forma segura sin realizar cambios en el código de la aplicación.
Capacidades de OCI Service Mesh
- Aplicación de Políticas Relacionadas con la Seguridad
OCI Service Mesh utiliza políticas de acceso para definir reglas de acceso. Las políticas de acceso aplican la comunicación entre microservicios y solo permiten solicitudes validadas que se originan dentro y fuera de la aplicación. Las políticas de acceso también se utilizan para definir la comunicación permitida a servicios externos.
- Confianza cero
OCI Service Mesh implementa automáticamente una arquitectura de seguridad de confianza cero en todos los microservicios. Los datos entre microservicios están cifrados. La identificación de microservicio a microservicio es necesaria al principio de la comunicación. Las dos partes deben intercambiar credenciales con su información de identidad. Esto permite que los servicios se identifiquen entre sí para determinar si están autorizados para interactuar. Esto se implanta con TLS mutua con rotación de claves y certificados automatizada mediante el servicio Oracle Cloud Infrastructure Certificates (OCI Certificates) y Oracle Key Management Cloud Service para gestionar certificados y claves.
- Cambio de tráfico
OCI Service Mesh permite realizar despliegues canarios. Cuando publica una nueva versión del código en producción, solo permite que una parte del tráfico llegue a ella. Esta función permite desplegar rápidamente y provoca la menor perturbación en la aplicación. Puede definir reglas de enrutamiento que rijan todas las comunicaciones entre microservicios dentro de la malla. Puede enrutar una parte del tráfico a una determinada versión del servicio.
- Supervisión y registro
OCI Service Mesh está en una posición única para proporcionar información de telemetría, ya que toda la comunicación entre microservicios debe pasar por ella. Esto permite que la malla de servicios capture datos de telemetría como origen, destino, protocolo, URL, duración, código de estado, latencia, registro y otras estadísticas detalladas. Puede exportar la información de registro al servicio Oracle Cloud Infrastructure Logging (OCI Logging). OCI Service Mesh proporciona dos tipos de logs: logs de errores y logs de tráfico. Puede utilizar estos logs para depurar problemas de 404 o 505 o para generar estadísticas basadas en logs. Los datos de métricas y telemetría se pueden exportar a Prometheus y visualizar con Grafana. Ambos se pueden desplegar directamente en un cluster de OKE.
Arquitectura
Oracle Cloud Infrastructure Service Mesh (OCI Service Mesh) utiliza un modelo de sidecar. Esta arquitectura encapsula el código que implementa la funcionalidad de red en un proxy de red y, a continuación, se basa en el tráfico desde y hacia los servicios que se redirigirán al proxy de sidecar. Se llama sidecar porque un proxy está unido a cada aplicación, al igual que un sidecar unido a una motocicleta. En OKE, el contenedor de la aplicación se encuentra junto al contenedor del sidecar proxy en el mismo pod. Como están en el mismo pod, comparten el mismo espacio de nombres de red y la misma dirección IP, lo que permite que los contenedores se comuniquen a través de "localhost".
- Plano de control
El plano de control de OCI Service Mesh gestiona y configura toda la recopilación de proxies para enrutar el tráfico. Maneja el reenvío, la comprobación del sistema, el equilibrio de carga, la autenticación, la autorización y la agregación de telemetría. El plano de control interactúa con el servicio de certificado de OCI y el servicio de gestión de claves de OCI para proporcionar a cada proxy su certificado.
- Plano de datos
El plano de datos se compone de la recopilación de proxies sidecar desplegados en el entorno y es responsable de la seguridad, las funciones de red y la observabilidad de la aplicación. También recogen e informan de la telemetría en todo el tráfico de malla. El proxy de Envoy se utiliza para el plano de datos de OCI Service Mesh.
El siguiente diagrama ilustra esta arquitectura de referencia.
oci_service_mesh_oke_arch-oracle.zip
Esta arquitectura de referencia muestra una aplicación desplegada en un cluster de OKE con tres servicios. El espacio de nombres en el que se despliega la aplicación se ha "ajustado". Un espacio de nombres "enmallado" indica que los servicios desplegados dentro del espacio de nombres formarán parte de una malla de servicios, y cada nuevo pod desplegado se inyectará con un contenedor de proxy de enviado. A medida que se despliega cada pod, el plano de control de OCI Service Mesh envía configuraciones y certificados a cada uno de los contenedores de proxy. El plano de control de OCI Service Mesh se comunica con el servicio de certificados de OCI y con Oracle Key Management Cloud Service para obtener certificados para cada proxy.
Se despliega un gateway de entrada para proporcionar acceso externo a la aplicación. El gateway de entrada forma parte del plano de datos de OCI Service Mesh y también es un proxy de enviado que recibe la configuración y los certificados del plano de control de OCI Service Mesh.
Es responsabilidad del contenedor proxy realizar la detección de servicios, el cifrado de tráfico y la autenticación con el servicio de destino. Los contenedores de proxy también aplican políticas de red, como la forma en que se distribuye el tráfico entre diferentes versiones de servicio y aplican políticas de acceso. El gateway de entrada realiza la misma función para el tráfico fuera de la malla de servicios.
Prometheus y Grafana se despliegan en el cluster de OKE en un espacio de nombres independiente que no forma parte de la malla de servicios. El plano de datos de malla de servicios envía estadísticas de funcionamiento clave, como latencia, fallos, solicitudes y telemetría, al despliegue de Prometheus. Grafana extrae datos del despliegue de Prometheus, que se puede utilizar para crear paneles de control para la visualización.
OCI Service Mesh está integrado con el servicio OCI Logging, y el registro se puede activar cuando se crea la malla de servicios. OCI Service Mesh proporciona dos tipos de logs: logs de errores y logs de tráfico. Estos logs se pueden utilizar para depurar problemas de 404 o 505 o para generar estadísticas basadas en logs.
Esta arquitectura tiene los siguientes servicios de OCI:
- OCI Kubernetes Engine (OKE)
Ofrece un cluster de Kubernetes escalable y de alta disponibilidad listo para producción para desplegar sus aplicaciones en contenedores en la nube.
- equilibrador de carga
Proporciona acceso al gateway de entrada en el cluster de OKE. La entrada dirige el tráfico a los servicios solicitados en el cluster de OKE.
- autoridad de certificación
Gestiona los certificados TLS para el servicio OCI Service Mesh.
- Key Management
Gestiona las claves utilizadas por el servicio de autoridad de certificación.
La arquitectura tiene los siguientes componentes:
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes entre sí y puede haber grandes distancias que las separen (entre países e incluso continentes).
- Red y subredes virtuales en la nube (VCN)
Una VCN es una red personalizable y definida por software que puede configurar en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan el control de su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se debe permitir dentro y fuera de la subred.
Recursos de OCI Service Mesh
| Recursos de Kubernetes | Descripción |
| Malla | La malla en el nivel superior es el contenedor lógico para todos los microservicios de la aplicación. |
| Servicio virtual | Un servicio virtual es una representación lógica del microservicio en una malla de servicios. |
| Despliegues virtuales | Un despliegue virtual es una representación lógica de un despliegue que se puede agrupar en un servicio virtual. Esto permite que un servicio virtual distribuya el tráfico entre diferentes versiones del microservicio. Un microservicio de Kubernetes puede tener varias versiones que son despliegues independientes en el cluster. |
| Enlaces de despliegue virtual | Los enlaces virtuales se utilizan para asociar un juego de pods a un despliegue virtual. |
| Tablas de rutas de servicio virtual | Una tabla de rutas virtuales define cómo se distribuye el tráfico entre los despliegues virtuales de un servicio virtual según el protocolo y la ruta. Cada servicio virtual tendrá una tabla de rutas virtuales. |
| Despliegue de gateway de entrada | Un despliegue de gateway de entrada creará pods de entrada que actuarán como equilibradores de carga para el tráfico entrante a la malla. |
| Gateways de entrada | Los gateways de entrada gestionan el tráfico de entrada en la malla. Los gateways de entrada definen un juego de reglas para la comunicación del tráfico externo con la malla, como si se necesita cifrado en todo el tráfico entrante y saliente. Estas reglas se aplican al despliegue del gateway de entrada. |
| Tablas de rutas de gateway de entrada | Las tablas de rutas de gateway de entrada están asociadas a un despliegue de gateway de entrada. La tabla de rutas define a qué servicios virtuales de la malla se puede acceder desde el despliegue del gateway de entrada. |
| Políticas de acceso | Las políticas de acceso son un juego de reglas que definen la comunicación permitida entre microservicios en la malla, así como aplicaciones externas. |
En el siguiente diagrama se muestra cómo se asignan los recursos de OCI Service Mesh configurados: Políticas de acceso, gateway de entrada, servicio virtual y despliegue virtual a los recursos de la aplicación: K8s Service, K8s Service Load Balancer, despliegues y pods.
Descripción de la ilustración oci_service_mesh_oke_config.png
Recomendaciones
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que planea asociar a las subredes de la VCN. Utilice bloques CIDR que estén dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques de CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) a la que desee configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Al diseñar las subredes, tenga en cuenta el flujo de tráfico y los requisitos de seguridad. Asocie todos los recursos de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
- Ancho de banda de equilibrador de carga
Al crear el equilibrador de carga, puede seleccionar una unidad predefinida que proporcione un ancho de banda fijo o especificar una unidad personalizada (flexible) en la que defina un rango de ancho de banda y permita que el servicio amplíe el ancho de banda automáticamente en función de los patrones de tráfico. Con cualquiera de los enfoques, puede cambiar la unidad en cualquier momento después de crear el equilibrador de carga.
Consideraciones
Tenga en cuenta las siguientes opciones al desplegar esta arquitectura de referencia.
- Costo
No hay ningún cargo por el plano de control de OCI Service Mesh en el cluster de OKE. Se cobra a los clientes por el uso de recursos de los contenedores de proxy para el plano de datos de Service Mesh. En la práctica, sin embargo, los clientes ya están pagando por los recursos para el pool de nodos en un cluster de OKE y, a menos que el uso de los contenedores de proxy transfiera el uso del pool de nodos más del 100%, no hay ningún cargo adicional por agregar OCI Service Mesh a la arquitectura de microservicios.
- Disponibilidad
El plano de control de OCI Service Mesh siempre se despliega con alta disponibilidad.