Bienvenue dans ce guide complet sur l’installation et la configuration de Kubernetes pour les architectures complexes. Destiné aussi bien aux débutants qu’aux utilisateurs expérimentés, ce guide vous fournira les informations et les étapes nécessaires pour déployer un cluster Kubernetes sur une infrastructure composée de trois nœuds maîtres et cinq nœuds de travail. Nous aborderons en détail la configuration réseau nécessaire, la mise en place des règles de pare-feu, ainsi que les différentes options de stockage telles que NFS, le stockage cloud, le stockage local, GlusterFS et Ceph. En plus de ces configurations essentielles, ce guide expliquera également comment mettre en œuvre Velero pour la sauvegarde et la restauration de votre cluster. Que vous cherchiez à comprendre les bases de Kubernetes ou à approfondir vos connaissances sur des aspects spécifiques tels que le stockage et la sauvegarde, ce guide est conçu pour vous accompagner étape par étape dans la création d’un environnement Kubernetes robuste, évolutif et sécurisé.
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/fstab1.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 enableEtape 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 update2.2 Installer kubeadm, kubelet, kubectl
sudo apt install kubelet kubeadm kubectl -y
sudo apt-mark hold kubelet kubeadm kubectlEtape 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/config3.3 Déployer un réseau de pods avec Calico
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml3.4 Ajouter les autres noeds master et workers
- Utilisez la commande
kubeadm joinfournie 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-namespacesEtapes 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: ImmediateII- 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: WaitForFirstConsumerapiVersion: 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-node2 – 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: WaitForFirstConsumer3 – 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: Immediate4 – 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: ImmediateChaque 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
III- BACKUP
Etape 1: Installation de Velero
1.1 Télécharger et installer le client Velero
- Velero s’installe à la fois comme un client CLI sur votre machine locale et comme un ensemble de services dans votre cluster Kubernetes. Le client CLI vous permet de gérer les sauvegardes et les restaurations.
- Téléchargez et installez le binaire Velero:
wget https://github.com/vmware-tanzu/velero/releases/download/v1.5.1/velero-v1.5.1-linux-amd64.tar.gz
tar -xzvf velero-v1.5.1-linux-amd64.tar.gz
sudo mv velero-v1.5.1-linux-amd64/velero /usr/local/bin/1.2 Installer le serveur Velero dans votre cluster Kubernetes
- Velero nécessite une configuration avec un fournisseur de stockage externe où les sauvegardes seront stockées, tel qu’Amazon S3, Google Cloud Storage, ou Azure Blob Storage. Pour cet exemple, je vais utiliser Amazon S3.
- Configurez un bucket S3 et une politique IAM appropriée pour Velero, puis installez Velero avec le plugin AWS:
cat > credentials-velero << EOF
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
EOF
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.1.0 \
--bucket <BUCKET_NAME> \
--backup-location-config region=<AWS_REGION> \
--snapshot-location-config region=<AWS_REGION> \
--secret-file ./credentials-veleroEtapes 2: Configuration des sauvegardes
2.1 Que sauvegarde Velero
- Ressources Kubernetes : Velero sauvegarde toutes les ressources Kubernetes dans les namespaces spécifiés, ou dans tout le cluster si aucun namespace n’est spécifié. Cela inclut les déploiements, les pods, les services, les configmaps, les secrets, etc.
- Volumes persistants : Si vos pods utilisent des volumes persistants, Velero peut également sauvegarder ces volumes en utilisant des instantanés du côté du fournisseur de cloud, assurant ainsi une récupération complète de l’état de vos applications.
2.2 Créer une sauvegarde programmée
Pour automatiser le processus de sauvegarde, vous pouvez créer des programmations basées sur la syntaxe cron :
velero create schedule <SCHEDULE_NAME> --schedule="0 7 * * *" --include-namespaces <NAMESPACE>2.3 Sauvegarde manuelle
Pour lancer une sauvegarde immediatement:
velero backup create <BACKUP_NAME> --include-namespaces <NAMESPACE>Etape 3: Restauration à partir d’une sauvegarde
3.1 Restaurer un cluster
Vous pouvez restaurer l’ensemble du cluster ou des parties spécifiques de celui-ci à partir d’une sauvegarde
velero restore create –from-backup
Etape 4: Vérification et maintenance
4.1 Vérifier l’état des sauvegardes:
velero backup get
velero backup describe <BACKUP_NAME> --details4.2 Gestion de l’espace de stockage
- Mettez en place des politiques de rétention pour gérer automatiquement l’espace de stockage en supprimant les anciennes sauvegardes.
En suivant ces étapes, vous mettez en place une solution complète de sauvegarde et de restauration pour votre cluster Kubernetes avec Velero. Cette configuration vous permet de récupérer rapidement en cas de perte de données ou de défaillance du cluster, tout en vous donnant un contrôle total sur ce qui est sauvegardé.