Aller au contenu principal

Chapitre 2.2 - API Server

Objectifs d'Apprentissage​

À la fin de ce chapitre, vous serez capable de:

  • Comprendre le rôle de l'API Server
  • Expliquer comment l'API Server valide et traite les requêtes
  • Comprendre l'authentification et l'autorisation
  • Utiliser kubectl pour interagir avec l'API Server

Qu'est-ce que l'API Server?​

L'API Server (kube-apiserver) est le point d'entrée unique pour toutes les interactions avec un cluster Kubernetes. C'est le seul composant avec lequel les utilisateurs et les autres composants du cluster communiquent directement.

Rôles de l'API Server​

1. Point d'Entrée Unique​

Toutes les requêtes passent par l'API Server:

  • kubectl → API Server
  • Dashboard → API Server
  • Contrôleurs → API Server
  • kubelet → API Server

2. Validation​

L'API Server valide toutes les requêtes:

  • Format correct (YAML/JSON)
  • Schéma respecté
  • Contraintes respectées

3. Authentification et Autorisation​

  • Authentification: Qui êtes-vous? (certificats, tokens, etc.)
  • Autorisation: Que pouvez-vous faire? (RBAC, ABAC, etc.)

4. Admission Control​

Plugins qui peuvent modifier ou rejeter les requêtes:

  • Validation des ressources
  • Mutations (ajout de valeurs par défaut)
  • Quotas et limites

Flux de Traitement d'une Requête​

API REST de Kubernetes​

L'API Server expose une API REST standard:

Endpoints Principaux​

/api/v1/namespaces/{namespace}/pods
/api/v1/namespaces/{namespace}/services
/api/v1/namespaces/{namespace}/deployments
/apps/v1/namespaces/{namespace}/deployments

Méthodes HTTP​

  • GET: Lire des ressources
  • POST: Créer des ressources
  • PUT: Mettre à jour des ressources
  • PATCH: Modifier partiellement
  • DELETE: Supprimer des ressources

Exemple avec kubectl​

# kubectl convertit les commandes en appels API REST
kubectl get pods
# Devient: GET /api/v1/namespaces/default/pods

kubectl create -f pod.yaml
# Devient: POST /api/v1/namespaces/default/pods

Authentification​

L'API Server supporte plusieurs méthodes d'authentification:

1. Certificats X.509​

2. Service Accounts​

Tokens pour les Pods qui communiquent avec l'API:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app

3. Tokens Statiques​

Fichiers de tokens pour l'authentification basique.

Autorisation (RBAC)​

Le contrôle d'accès basé sur les rôles (RBAC) détermine ce qu'un utilisateur peut faire:

Exemple de Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Admission Control​

Les Admission Controllers sont des plugins qui interceptent les requêtes:

Types d'Admission Controllers​

  1. Validating: Valident et peuvent rejeter
  2. Mutating: Modifient les requêtes avant stockage

Exemples​

  • ResourceQuota: Limite les ressources par namespace
  • LimitRanger: Applique des limites par défaut
  • PodSecurityPolicy: Applique des politiques de sécurité

Performance et Scalabilité​

Optimisations​

  • Watch API: Notifications en temps réel au lieu de polling
  • Pagination: Limite le nombre de résultats
  • Field Selectors: Filtre les résultats côté serveur

Métriques Importantes​

  • Latence des requêtes
  • Débit (requêtes/seconde)
  • Taille des réponses

Commandes Utiles​

# Voir les endpoints de l'API
kubectl get --raw /

# Voir les ressources disponibles
kubectl api-resources

# Voir les versions d'API
kubectl api-versions

# Tester directement l'API
kubectl proxy
# Puis: curl http://localhost:8001/api/v1/pods

Résumé​

Dans ce chapitre, vous avez appris:

API Server: Point d'entrée unique pour toutes les interactions
Validation: Vérifie le format et le schéma des requêtes
Sécurité: Authentification et autorisation (RBAC)
Admission Control: Plugins pour validation et mutation
API REST: Interface standard pour interagir avec Kubernetes

Prochaines Étapes​

Maintenant que vous comprenez l'API Server:

Chapitre 2.3: etcd - La Base de Données du Cluster
Chapitre 2.4: Controller Manager

Chapitre créé le: Décembre 2024