Kubernetes & Rancher — Introduction

Lexique des concepts K8s et des composants utilisés sur le cluster. Usage pratique de Rancher au quotidien pour ce repo : voir infra.md.

Lexique K8s

DaemonSet

• Pop 1 pod par nœud

Déploiement

• Objet qui pop des pods, et contrairement au DaemonSet, il n'est pas conscient des Nodes, il pop un pod quelque part
• Si on met le replica à 1, on a un pod par Déploiement
• Le volume est partagé entre les pods replica
• Ça sert par exemple quand tu dois partager un dossier de sessions en fichiers plats

StatefulSet

• Comme un déploiement, mais on réclame un volume de stockage PAR pod
• Si un seul replica, ça revient au même
• Ça sert pour faire un cluster de DB : on ne veut pas que les 2-3 pods modifient le même volume de DB, par contre les volumes se sync entre eux, donc on partage les ressources de lecture/écriture, mais la donnée est la même

Controller Network Interface (CNI)

• Quand K8s pop 1 pod, la CNI va lui assigner une IP interne automatiquement
• Il y a un DNS interne qui se met à jour régulièrement

Application

• Concept Rancher (pas un objet K8s natif) : regroupe Déploiement + Service + Ingress dans l'UI Rancher — voir infra.md

Pod

• Prend des secrets et des configmap

Network Policy

• Règles des ouvertures de flux entre les pods
• ⚠️ Actuellement, tous les flux sont ouverts
• Le fonctionnement actuel est donc d'utiliser les NP pour fermer un flux, et pas pour l'ouvrir
• À changer dans le futur

Ingress

• Routage de l'extérieur vers 1 service qui lui-même redirige vers le pod
• Génère des fichiers de configuration qu'il envoie à Kong qui les applique

Service

• A une IP stable, et un DNS interne qui distribue le trafic vers un Pod ou un ensemble de Pods

Ingress Controller

• Reverse proxy, on utilise Kong actuellement, et pas Nginx
• Il faudrait changer ça un jour

Stockage

• K8s ne fait pas de stockage, il implémente des objets de base qui font du stockage
• CSI (Container Storage Interface)

Ressources

• En général on ne met pas de limite de CPU
• Les limites de CPU sont exprimées en millième de CPU
• Il y a le request et le limit

PersistentVolume

• Disque provisionné dans le cluster, créé par une PVC (Persistent Volume Claim)
• Le pod génère une PVC

CSI (Container Storage Interface)

• Interface standardisée entre K8s et les solutions de stockage
• Longhorn implémente CSI

Composants

Rancher

• Rancher est un proxy de l'API de Kube au-dessus de Kubectl : il prend du yaml, le traduit en demandes à l'API Kube qui elle-même ordonne au controller manager la création de Pods

Longhorn

• Chaque nœud du cluster expose son stockage local
• Quand on crée un volume, Longhorn le réplique sur N nœuds ; si un nœud tombe, les répliques prennent le relai
• Création : définition d'une StorageClass avec provider driver.longhorn.io, un pod référence la PVC, le pod voit un filesystem classique

Kong

• Reverse proxy

HelmChart

• Templates de configuration de déploiements
• À mettre à jour de temps en temps

Role Based Access Control (RBAC)

K8s utilise RBAC : l'idée est de définir qui peut faire quoi sur quelles ressources.

• Role — Définit des permissions dans un namespace donné
• ClusterRole — Définit des permissions sur tout le cluster, ou sur des ressources non-namespacées (nodes, PV, namespaces eux-mêmes...)
• RoleBinding — Lie un sujet à un Role (ou un ClusterRole) dans un namespace
• ClusterRoleBinding — Lie un sujet à un ClusterRole sur tout le cluster

Un ClusterRole peut être réutilisé avec un simple RoleBinding pour appliquer des permissions génériques sans les redéfinir par namespace :

La combinaison classique pour un outil comme Longhorn : un ClusterRole (car il doit accéder aux nodes, PV, et plusieurs namespaces) + un ClusterRoleBinding vers son ServiceAccount.

Ajouter une variable d'env dans Rancher

Pour ajouter une variable d'env sur Rancher il faut aller dans Apps -> installedApps -> settings -> Edit/Upgrade -> Values

Dans ce fichier ajouter la variable d'env voulue (dans deployments / extraEnvVars) -> Tout en bas appuyer sur update

⚠️ En prod il faut également modifier dans deployments -> image -> tag le numéro de version pour que ça coincide avec celui actuellement en prod : cf (https://status.article-1.eu/)