Kubernetes pour les nuls

I – INSTALLATION

Etape 1: Préparation des noeuds

1.1 Configuration du système

Assignez une adresse IP statique à chaque machine
Assurez vous que les systèmes soit à jour:

sudo apt update && sudo apt upgrade -y

Définissez un nom d’hôte unique pour chaque noeud

sudo hostnamectl set-hostname <nom-du-nœud>

Désactivez le swap:

sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

1.2 Installer Docker

Ouvrez les port nécessaires pour kubernetes:

sudo apt install apt-transport-https ca-certificates curl software-properties-common -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt update
sudo apt install docker-ce -y
sudo systemctl enable docker
sudo systemctl start docker
sudo usermod -aG docker ${USER}

1.3 Configurez le pare-feu

sudo ufw allow 6443/tcp      # kube-apiserver
sudo ufw allow 2379:2380/tcp # etcd server client API
sudo ufw allow 10250/tcp     # kubelet API
sudo ufw allow 10251/tcp     # kube-scheduler
sudo ufw allow 10252/tcp     # kube-controller-manager
sudo ufw allow 30000:32767/tcp # NodePort Services
sudo ufw enable

Etape 2: Installation des composants Kubernetes

Sur tous les noeuds:

2.1 Ajouter le dépôt Kubernetes

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update

2.2 Installer kubeadm, kubelet, kubectl

sudo apt install kubelet kubeadm kubectl -y
sudo apt-mark hold kubelet kubeadm kubectl

Etape 3: Initialisation du cluster et ajout de noeuds

3.1 Initialiser le cluster sur le premier noeud maître

sudo kubeadm init --control-plane-endpoint "master1_ip:6443" --upload-certs --pod-network-cidr=192.168.0.0/16

–control-plane-endpoint est l’adresse IP ou le DNS utilisé pour atteindre l’API Kubernetes.
–upload-certs partage automatiquement les certificats nécessaires entre les nœuds maîtres.

3.2 Configurer kubectl pour un utilisateur non-root

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

3.3 Déployer un réseau de pods avec Calico

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

3.4 Ajouter les autres noeds master et workers

Utilisez la commande kubeadm join fournie après l’initialisation du premier maître pour joindre les autres nœuds maîtres et travailleurs au cluster.

Etapes 4: Vérification du cluster

Vérifiez l’état des noeuds et des pods:

kubectl get nodes
kubectl get pods --all-namespaces

Etapes 5: Configuration de la persistence et du stockage

Installer un provisionneur de stockage, par exemple NFS ou une solution de stockage cloud, et configurer les StorageClasses appropriées pour le provisionnement dynamique des volumes.

Configurer un serveur NFS sur un noeud externe(non couvert ici)
Installer le provisionneur NFS

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/nfs-subdir-external-provisioner/latest/deploy/kubernetes/deployment.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/nfs-subdir-external-provisioner/latest/deploy/kubernetes/class.yaml

Configurez un storageClass. Les PVCs utiliseront cette StorageClass pour demander de l’espace de stockage du provisionneur configuré.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: nfs-storage
provisioner: nfs-subdir-external-provisioner # doit correspondre au provisionneur installé
reclaimPolicy: Delete
volumeBindingMode: Immediate

II- STOCKAGE

En plus du NFS, Kubernetes supporte une variété d’options pour la gestion du stockage, notamment les solutions de stockage local, les solutions de stockage en cloud, et des technologies plus spécialisées. Voici quelques options populaires :

1- Stockage local

Le stockage local utilise les disques physiques ou les partitions présentes sur le nœud Kubernetes lui-même.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-local-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - example-node

2 – Cloud provider storage

Les solutions de stockage de fournisseurs de cloud comme AWS EBS, Azure Disk, et Google Persistent Disk sont également largement utilisées. Prenons AWS EBS par exemple:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp2
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

3 – Ceph RBD

Ceph est une solution de stockage distribué qui peut être utilisée avec Kubernetes via RBD (RADOS Block Device).

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ceph-rbd
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.245.0.1:6789,10.245.0.2:6789
  adminId: admin
  adminSecretName: ceph-admin-secret
  pool: kube
  userId: kube
  userSecretName: ceph-secret
reclaimPolicy: Retain
volumeBindingMode: Immediate

4 – GlusterFS

GlusterFS est un système de fichiers en mode cluster qui peut être utilisé pour stocker les données de Kubernetes

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-heketi
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://heketi-storage.gluster.svc.cluster.local:8080"
  restuser: "admin"
  secretNamespace: "default"
  secretName: "heketi-secret"
reclaimPolicy: Retain
volumeBindingMode: Immediate

Chaque option a ses propres avantages et inconvénients, et le choix dépendra de vos besoins spécifiques, de l’échelle de votre environnement, et des coûts associés. Il est important de noter que chaque option de stockage peut nécessiter une configuration supplémentaire du côté du cluster ou des pré-requis d’infrastructure pour fonctionner correctement.

5 – Différence entre Ceph et GlusterFS

Les différences entre Ceph RBD et GlusterFS résident principalement dans leur architecture, leur mode de fonctionnement, et les cas d’utilisation pour lesquels ils sont le mieux adaptés. Voici un aperçu détaillé des différences entre ces deux solutions de stockage distribué :

Ceph RBD (RADOS Block Device)

Architecture et Fonctionnement :

Ceph est un système de stockage distribué qui fournit trois types principaux de stockage : objet, bloc, et fichier. Ceph RBD fait référence à la partie « bloc » de Ceph.
RBD utilise le système de stockage orienté objet de Ceph (RADOS) pour stocker des images disque, qui peuvent être montées comme des disques durs par des machines virtuelles ou des pods Kubernetes.
Les données dans Ceph sont réparties et répliquées automatiquement à travers tout le cluster, offrant une haute disponibilité et résilience.

Cas d’Utilisation :

RBD est bien adapté pour des scénarios où les performances d’I/O de bloc sont critiques, tels que les bases de données ou d’autres charges de travail nécessitant un accès rapide et fiable au stockage.
Il offre une forte cohérence des données et une capacité de redondance, ce qui est essentiel pour les applications critiques.

Avantages :

Fournit une redondance des données et une tolérance aux pannes en distribuant automatiquement les données.
Supporte les snapshots et le clonage, ce qui est utile pour les environnements de production et de test.
Évolutivité massive sans point unique de défaillance.

GlusterFS

Architecture et Fonctionnement :

GlusterFS est un système de fichiers distribué qui agrège diverses ressources de stockage en réseau pour créer un seul système de fichiers global.
GlusterFS utilise des « bricks », des unités de stockage sur les serveurs individuels, qui sont combinés en volumes. Les données sont distribuées et répliquées à travers ces bricks selon la configuration du volume.
Il est basé sur une architecture sans métadonnées centralisées, ce qui permet à GlusterFS de mieux évoluer horizontalement.

Cas d’Utilisation :

GlusterFS est souvent utilisé pour des applications qui nécessitent de grandes capacités de stockage de fichiers et un accès simultané par de nombreux clients, comme le contenu multimédia, les archives de documents, et les sauvegardes.
C’est une bonne solution pour les partages de fichiers dans un environnement multi-client grâce à sa flexibilité et facilité d’accès.

Avantages :

Simple à déployer et à gérer grâce à sa structure sans métadonnées centralisées.
Évolutivité horizontale facile, permettant l’ajout de capacité de stockage sans interruption.
Bonne performance pour les applications à large bande passante et faible latence.

Comparaison et Choix

Performance: Ceph RBD peut offrir de meilleures performances pour les accès aléatoires en lecture/écriture car il est optimisé pour les opérations de stockage de bloc. GlusterFS, bien qu’efficace pour le streaming de données et les accès en lecture, peut ne pas performer aussi bien que Ceph pour des charges de travail intensives en I/O.
Gestion et Scalabilité: GlusterFS est souvent loué pour sa facilité de gestion et son architecture flexible, tandis que Ceph peut être plus complexe à configurer et à maintenir mais offre une meilleure évolutivité et performance pour les environnements exigeants.
Cas d’usage: Le choix entre Ceph et GlusterFS dépendra largement du type d’accès aux données requis par vos applications. Ceph est généralement préféré pour les environnements nécessitant une haute performance et une haute disponibilité de stockage de bloc, tandis que GlusterFS est adapté pour les solutions de stockage de fichiers à grande échelle.

En résumé, le choix entre Ceph RBD et GlusterFS doit être guidé par les exigences spécifiques de votre charge de travail, vos objectifs de performance, et vos préférences en termes de gestion et de maintenance