Premier aperçu des Kubernetes Service APIs

Préface

Nous savons que Kubernetes dispose de plusieurs solutions pour exposer les services à l'intérieur du cluster, l'une des plus populaires étant Ingress, qui est une norme pour exposer les services vers l'extérieur et possède plusieurs implémentations tierces, chacune avec sa propre pile technologique et ses dépendances sur des passerelles qui ne sont pas compatibles entre elles.

Afin d'unifier les différentes implémentations d'Ingress et de faciliter une gestion uniforme sur Kubernetes, la communauté SIG-NETWORK a publié les Kubernetes Service APIs, un ensemble d'implémentations standard appelées Ingress de deuxième génération.

Description du sujet

Cet article fournit une introduction aux concepts de base des Kubernetes Service APIs, en commençant par quelques questions.

Introduction

Les Kubernetes Service APIs sont appelés la deuxième génération de la technologie Ingress, mais en quoi sont-ils meilleurs que la première génération

Les Kubernetes Service APIs n'ont pas été conçus pour se limiter à Ingress, mais plutôt pour améliorer le réseau de services en se concentrant sur les aspects suivants : expressivité, extensibilité et RBAC.

1. Plus de fonctionnalités, par exemple, la gestion du trafic basée sur l'en-tête, le poids.

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

2. Amélioration de l'extensibilité, les Service APIs introduisent le concept d'une API multi-couches, chaque couche exposant sa propre interface, permettant à d'autres ressources personnalisées d'interagir avec l'API pour un contrôle plus fin (au niveau de l'API).

3. RBAC orienté rôle : La réalisation d'une API multi-couches, l'une des idées est de concevoir des objets de ressources du point de vue des utilisateurs. Ces ressources seront finalement mappées avec les rôles communs d'exécution d'applications sur Kubernetes.

Quels objets de ressources sont abstraits par les Kubernetes Service APIs

Basé sur les rôles des utilisateurs, les Kubernetes Service APIs définiront les ressources suivantes :

GatewayClass, Gateway, Route

1. GatewayClass définit un ensemble de types de passerelles avec une configuration et un comportement communs :

• Relation avec Gateway, similaire à l'annotation ingess.class dans ingress ;
• Un GatewayClass définit un groupe de passerelles qui partagent la même configuration et le même comportement. Chaque GatewayClass sera géré par un seul contrôleur, avec une relation un-à-plusieurs entre le contrôleur et le GatewayClass ;
• GatewayClass est une ressource de cluster. Au moins un GatewayClass doit être défini pour avoir une passerelle fonctionnelle.

2. Gateway demande un point où le trafic peut être converti en services à l'intérieur du cluster :

• Ce qu'il fait : amène le trafic de l'extérieur du cluster à l'intérieur du cluster. C'est l'entité ingress réelle ;
• Il définit une demande pour une configuration LB spécifique qui est également l'implémentation de la configuration et du comportement du GatewayClass ;
• Les ressources Gateway peuvent être créées directement par l'opérateur ou par le contrôleur gérant le GatewayClass ;
• Gateway et Route sont dans une relation plusieurs-à-plusieurs.

3. Route décrit comment le trafic passant par une passerelle est mappé à un service.

En outre, les Kubernetes Service APIs définissent un objet de ressource BackendPolicy afin de permettre une configuration flexible des services backend.

L'objet BackendPolicy vous permet de configurer TLS, les vérifications de santé et de spécifier le type de service backend, tel que service ou pod.

Quels changements l'introduction des Kubernetes Service APIs apportera-t-elle

Les Kubernetes Service APIs, en tant que norme d'implémentation, apportent les changements suivants.

1. Généralité : il peut y avoir plusieurs implémentations, tout comme il existe plusieurs implémentations d'ingress. Les contrôleurs ingress peuvent être personnalisés selon les caractéristiques de la passerelle, mais ils ont tous une structure de configuration cohérente. Une structure de données peut être utilisée pour configurer plusieurs contrôleurs ingress.
2. Le concept de classes : GatewayClasses permet la configuration de différents types d'implémentations d'équilibrage de charge. Ces classes permettent à l'utilisateur de comprendre facilement et explicitement quelles fonctions peuvent être utilisées comme modèles de ressources eux-mêmes.
3. Passerelles partagées : En permettant à des ressources de routage indépendantes HTTPRoute d'être liées au même GatewayClass, elles peuvent partager des équilibreurs de charge et des VIP. Stratifiées par utilisateur, cela permet aux équipes de partager en toute sécurité l'infrastructure sans avoir à se soucier de l'implémentation spécifique du Gateway de niveau inférieur.
4. Références backend avec types : Avec des références backend avec types, les routes peuvent référencer des Kubernetes Services, ou tout type de ressource Kubernetes conçue comme un backend de passerelle, comme un pod, ou un statefulset tel qu'une base de données, ou même une ressource externe accessible au cluster.
5. Références inter-namespaces : Les routes à travers différents namespaces peuvent être liées à un Gateway, permettant un accès mutuel entre les namespaces. Il est également possible de restreindre la plage de namespaces qu'une Route sous un Gateway peut accéder.

Quelles implémentations d'Ingress des Kubernetes Service APIs sont actuellement disponibles

Les Ingress connus pour supporter les objets de ressources des Kubernetes Service APIs au niveau du code sont Contour, ingress-gce.

Comment les Kubernetes Service APIs gèrent-ils les permissions de lecture et d'écriture des ressources

Les Kubernetes Service APIs sont divisés en 3 rôles basés sur la dimension utilisateur :

1. fournisseur d'infrastructure GatewayClass ;
2. opérateur de cluster Gateway ;
3. développeur d'application Route.

RBAC (Contrôle d'Accès Basé sur les Rôles) est la norme utilisée pour l'autorisation Kubernetes. Il permet aux utilisateurs de configurer qui peut effectuer des opérations sur une plage spécifique de ressources. RBAC peut être utilisé pour activer chacun des rôles définis ci-dessus.

Dans la plupart des cas, il est prévu que tous les rôles puissent lire toutes les ressources.

Le modèle à trois niveaux a les permissions d'écriture suivantes.

Quels sont les points d'extension des Kubernetes Service APIs

Les exigences pour les passerelles sont très riches, et il existe de nombreuses façons d'implémenter le même scénario, chacune avec ses avantages et inconvénients. Les Kubernetes Service APIs ont extrait des objets de ressources multi-couches, et ont également réservé certains points d'extension.

Les Kubernetes Service APIs se concentrent actuellement sur Route :

• RouteMatch étend les règles de correspondance de Route.
• spécifier Backend étend les types spécifiques de services backend, tels que les systèmes de fichiers, les expressions de fonctions, etc., en plus des ressources Kubernetes mentionnées ci-dessus.
• Le filtre de Route ajoute des extensions au cycle de vie de Route pour traiter les requêtes/réponses.
• Si aucune des extensions ci-dessus ne peut être satisfaite par une Route personnalisée, une Route peut être entièrement personnalisée.

Résumé

Cet article a fourni une introduction de base aux Kubernetes Service APIs en posant des questions. Dans l'ensemble, les Kubernetes Service APIs affinent de nombreuses meilleures pratiques d'Ingress, telles que l'expressivité améliorée, qui étend en fait les capacités de Route, et les objets BackendPolicy, qui peuvent spécifier presque n'importe quelle ressource backend Kubernetes pour l'amont. Les Kubernetes Service APIs spécifient actuellement les objets de ressources à un niveau large, mais il reste encore de nombreux détails à discuter au sein des objets de ressources avant qu'ils ne puissent être définis pour prévenir les scénarios de conflit possibles, et il y a certaines variables dans la structure.