Aller au contenu

Module 3 · Administration cluster

Objectifs

  • RBAC : qui a le droit de faire quoi.
  • Ressources & quotas : requests/limits, LimitRange, ResourceQuota.
  • Helm : déployer une app packagée.
  • Ingress + TLS et réseau : du clic au pod.
  • Troubleshooting systématique.
  • Durée : ~5 h · Pré-requis : Module 2.

1. RBAC — Role Based Access Control

Quatre objets, deux niveaux de portée :

graph LR
    SA[ServiceAccount / User] --> RB[RoleBinding]
    RB --> R[Role]
    R --> V[Verbes sur ressources]
    SA --> CRB[ClusterRoleBinding]
    CRB --> CR[ClusterRole]
Objet Portée Rôle
Role Un namespace Liste de permissions (verbes × ressources)
ClusterRole Tout le cluster Idem, à l'échelle cluster
RoleBinding Un namespace Attribue un Role à un sujet (user/SA/group)
ClusterRoleBinding Cluster Idem à l'échelle cluster

```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: lecteur-pods rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev name: antoine-lecteur subjects: - kind: ServiceAccount name: antoine namespace: dev roleRef: kind: Role name: lecteur-pods apiGroup: rbac.authorization.k8s.io ```

bash kubectl auth can-i get pods --as=system:serviceaccount:dev:antoine -n dev # yes kubectl auth can-i delete pods --as=system:serviceaccount:dev:antoine -n dev # no

C'est exactement comme ça que TA sandbox est isolée

Ton accès à la sandbox repose sur ce mécanisme (ici poussé au max via vcluster : tu es admin d'un cluster virtuel, sans aucun droit sur le cluster hôte).

2. Ressources : requests, limits, quotas

yaml resources: requests: # ce que le scheduler réserve cpu: "100m" memory: "128Mi" limits: # plafond ; au-delà → throttle (CPU) ou OOMKill (mémoire) cpu: "500m" memory: "256Mi"

  • requests = garanti, sert au scheduling.
  • limits = plafond. Dépasser la mémoire → le pod est OOMKilled.
  • ResourceQuota (par namespace) plafonne la somme ; LimitRange impose des défauts.

Exercice 3.1 — OOMKill

Déploie un pod avec limits.memory: 32Mi qui alloue 100 Mo. Observe dans k9s l'état OOMKilled et retrouve-le dans le describe.

3. Helm en 5 minutes

Helm = le « apt/npm » de Kubernetes : des charts paramétrables par un fichier values.yaml.

bash helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update helm install monsite bitnami/nginx helm list helm upgrade monsite bitnami/nginx --set replicaCount=3 helm uninstall monsite

Exercice 3.2 — Déployer via Helm

Installe un chart simple, observe les objets créés dans k9s (:deploy, :svc, :cm), puis fais un helm upgrade et regarde le rolling update se déclencher.

4. Ingress, Service, TLS : le chemin d'une requête

graph LR
    U[Navigateur] --> I[Ingress]
    I --> S[Service]
    S --> P1[Pod]
    S --> P2[Pod]
Type de Service Usage
ClusterIP Interne au cluster (défaut)
NodePort Expose un port sur chaque nœud
LoadBalancer Demande un LB au cloud provider (cf. EKS)

L'Ingress route le HTTP(S) par hôte/chemin vers des Services. Le TLS est géré ici (dans l'infra de Timothé : Traefik + cert-manager / Let's Encrypt).

Exercice 3.3 — Du Service à l'Ingress

  1. Crée un deployment web + un Service ClusterIP.
  2. kubectl get endpoints web : le Service pointe-t-il bien sur les pods ?
  3. Crée un Ingress qui route web.local → Service web. Vérifie dans k9s (:ing).

5. Méthode de troubleshooting

Checklist universelle

  1. Pod : Running ? Sinon → describe → events.
  2. Logs : erreur applicative ? (--previous si crash).
  3. Service : kubectl get endpoints — pointe-t-il sur des pods ?
  4. Réseau : kubectl port-forward directement sur le pod, ça marche ?
  5. Ingress : host/path corrects ? Certif TLS émis ?
  6. Ressources : kubectl top, OOMKilled, quotas atteints ?

6. Ce qu'il faut retenir

  • RBAC = verbes × ressources × sujet × portée. auth can-i pour vérifier.
  • requests/limits pilotent scheduling et stabilité (OOMKill).
  • Helm package et paramètre ; Ingress route et fait le TLS.
  • Le troubleshooting suit toujours le chemin Pod → Service → Ingress.

➡️ Suite : Module 3b — Stockage persistant