Una primera mirada a las APIs de Kubernetes Service

Prefacio

Sabemos que Kubernetes tiene varias soluciones para exponer servicios dentro del clúster, una de las más populares es Ingress, que es un estándar para exponer servicios al mundo exterior y tiene varias implementaciones de terceros, cada una con su propia pila tecnológica y dependencias de gateways que no son compatibles entre sí.

Para unificar las diversas implementaciones de Ingress y facilitar la gestión uniforme en Kubernetes, la comunidad SIG-NETWORK ha lanzado Kubernetes Service APIs, un conjunto de implementaciones estándar llamadas Ingress de segunda generación.

Descripción del tema

Este artículo proporciona una introducción a los conceptos básicos de Kubernetes Service APIs, comenzando con algunas preguntas.

Introducción

Las Kubernetes Service APIs se denominan la segunda generación de tecnología Ingress, pero ¿en qué aspectos son mejores que la primera generación?

Las Kubernetes Service APIs no fueron diseñadas para limitarse a Ingress, sino para mejorar la red de servicios con un enfoque en lo siguiente: expresividad, escalabilidad y RBAC.

1. Más características, por ejemplo, gestionar el tráfico basado en el encabezado, peso.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
---
matches:
  - path:
      value: "/foo"
    headers:
      values:
        version: "2"
  - path:
      value: "/v2/foo"

2. Mejorando la escalabilidad, las Service APIs introducen el concepto de una API de múltiples capas, donde cada capa expone su propia interfaz, permitiendo que otros recursos personalizados se conecten a la API para un control más granular (a nivel de API).

3. RBAC orientado a roles: La realización de una API de múltiples capas, una de las ideas es diseñar objetos de recursos desde la perspectiva de los usuarios. Estos recursos eventualmente se mapearán con los roles comunes de ejecución de aplicaciones en Kubernetes.

¿Qué objetos de recursos son abstraídos por las Kubernetes Service APIs?

Basándose en los roles de los usuarios, las Kubernetes Service APIs definirán los siguientes recursos:

GatewayClass, Gateway, Route

1. GatewayClass define un conjunto de tipos de gateways con configuración y comportamiento comunes:

• Relación con Gateway, similar a la anotación ingess.class en ingress;
• Un GatewayClass define un grupo de gateways que comparten la misma configuración y comportamiento. Cada GatewayClass será manejado por un solo controlador, con el controlador teniendo una relación de uno a muchos con el GatewayClass;
• GatewayClass es un recurso de clúster. Se debe definir al menos un GatewayClass para tener un gateway funcional.

2. Gateway solicita un punto en el que el tráfico puede convertirse en servicios dentro del clúster:

• Lo que hace: lleva el tráfico desde fuera del clúster hacia dentro del clúster. Esta es la entidad de ingress real;
• Define una solicitud para una configuración específica de LB que también es la implementación de la configuración y comportamiento del GatewayClass;
• Los recursos de Gateway pueden ser creados directamente por el operador o por el controlador que maneja el GatewayClass;
• Gateway y Route tienen una relación de muchos a muchos.

3. Route describe cómo el tráfico que pasa por un gateway se mapea a un servicio.

Además, las Kubernetes Service APIs definen un objeto de recurso BackendPolicy para permitir una configuración flexible de los servicios backend.

El objeto BackendPolicy permite configurar TLS, verificaciones de salud y especificar el tipo de servicio backend, como servicio o pod.

¿Qué cambios traerá la introducción de las Kubernetes Service APIs?

Las Kubernetes Service APIs, como un estándar de implementación, traen los siguientes cambios.

1. Generalidad: puede haber múltiples implementaciones, al igual que hay múltiples implementaciones de ingress. Los controladores de ingress pueden personalizarse según las características del gateway, pero todos tienen una estructura de configuración consistente. Una estructura de datos puede usarse para configurar múltiples controladores de ingress.
2. El concepto de clases: GatewayClasses permite la configuración de diferentes tipos de implementaciones de balanceo de carga. Estas clases permiten al usuario comprender fácil y explícitamente qué funciones pueden usarse como modelos de recursos en sí mismos.
3. Gateways compartidos: Al permitir que recursos de enrutamiento independientes HTTPRoute se vinculen al mismo GatewayClass, pueden compartir balanceadores de carga y VIPs. Estratificado por usuario, esto permite que los equipos compartan de manera segura la infraestructura sin tener que preocuparse por la implementación específica del Gateway de nivel inferior.
4. Referencias backend con tipos: Con referencias backend con tipos, las rutas pueden hacer referencia a Kubernetes Services, o cualquier tipo de recurso de Kubernetes diseñado como backend de gateway, como un pod, o un statefulset como una DB, o incluso un recurso externo accesible al clúster.
5. Referencias cruzadas entre namespaces: Las rutas a través de diferentes namespaces pueden vincularse a un Gateway, permitiendo el acceso entre namespaces. También es posible restringir el rango de namespaces que una Route bajo un Gateway puede acceder.

¿Qué implementaciones de Ingress de Kubernetes Service APIs están disponibles actualmente?

Los Ingress que se sabe que admiten los objetos de recursos de Kubernetes Service APIs a nivel de código son Contour, ingress-gce.

¿Cómo gestionan las Kubernetes Service APIs los permisos de lectura y escritura de recursos?

Las Kubernetes Service APIs se dividen en 3 roles basados en la dimensión del usuario:

1. proveedor de infraestructura GatewayClass;
2. operador de clúster Gateway;
3. desarrollador de aplicaciones Route.

RBAC (Control de Acceso Basado en Roles) es el estándar utilizado para la autorización en Kubernetes. Permite a los usuarios configurar quién puede realizar operaciones en un rango específico de recursos. RBAC puede usarse para habilitar cada uno de los roles definidos anteriormente.

En la mayoría de los casos, se espera que todos los roles puedan leer todos los recursos.

El modelo de tres niveles tiene los siguientes permisos de escritura.

¿Cuáles son los puntos de extensión para las Kubernetes Service APIs?

Los requisitos para los gateways son muy ricos, y hay muchas formas de implementar el mismo escenario, cada una con sus propias ventajas y desventajas. Las Kubernetes Service APIs han extraído objetos de recursos de múltiples capas, y también han reservado algunos puntos de extensión.

Las Kubernetes Service APIs actualmente se centran en Route:

• RouteMatch extiende las reglas de coincidencia de Route.
• especificar Backend extiende tipos específicos de servicios backend, como sistemas de archivos, expresiones de funciones, etc., además de los recursos de Kubernetes mencionados anteriormente.
• El filtro de Route agrega extensiones al ciclo de vida de Route para manejar solicitudes/respuestas.
• Si ninguna de las extensiones anteriores puede ser satisfecha por una Route personalizada, se puede personalizar completamente una Route.

Resumen

Este artículo ha proporcionado una introducción básica a las Kubernetes Service APIs mediante preguntas. En general, las Kubernetes Service APIs refinan muchas de las mejores prácticas de ingress, como la expresividad mejorada, que en realidad extiende las capacidades de Route, y los objetos BackendPolicy, que pueden especificar casi cualquier recurso backend de Kubernetes para el upstream. Las Kubernetes Service APIs actualmente especifican los objetos de recursos a un nivel amplio, pero todavía hay muchos detalles dentro de los objetos de recursos que deben discutirse antes de que puedan definirse para prevenir posibles escenarios de conflicto, y hay ciertas variables en la estructura.