Appliquer le Manifest YAML
Dans cette étape, vous allez explorer la commande kubectl apply plus en détail et apprendre différentes manières d'appliquer les manifests Kubernetes. En nous basant sur les fichiers YAML de l'étape précédente, nous allons démontrer diverses techniques pour appliquer les manifests.
Tout d'abord, assurez-vous d'être dans le bon répertoire :
cd ~/project/k8s-manifests
Créons un nouveau sous-répertoire pour organiser davantage nos manifests. Créez un répertoire nommé manifests et naviguez à l'intérieur :
mkdir -p manifests
cd manifests
Maintenant, créons un manifest pour une application web simple qui inclut à la fois un Deployment et un Service dans un seul fichier. Créez un nouveau fichier nommé web-app.yaml en utilisant nano :
nano web-app.yaml
Ajoutez le contenu suivant à web-app.yaml :
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:alpine
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
type: ClusterIP
ports:
- port: 80
targetPort: 80
Ce manifest définit deux ressources Kubernetes dans un seul fichier, séparées par ---. C'est une façon courante de regrouper des ressources connexes. Décomposons ce qui est nouveau :
- Ressources Multiples dans un Seul Fichier : Le fichier
web-app.yaml contient maintenant deux définitions de ressources Kubernetes distinctes : un Deployment et un Service. Le séparateur --- est utilisé pour les distinguer.
kind: Service : Ceci définit une ressource Service.
spec.selector.app: web : Ce Service ciblera les pods qui ont l'étiquette app: web. Cela correspond aux étiquettes que nous avons définies pour les pods créés par le Deployment web-app.spec.type: ClusterIP : Spécifie le type de service comme ClusterIP. Cela signifie que le service sera exposé sur une adresse IP interne au sein du cluster et est généralement utilisé pour la communication entre les services au sein du cluster.spec.ports : Définit comment le service mappe les ports aux pods cibles.
port: 80 : Le port sur le Service lui-même auquel vous accéderez.targetPort: 80 : Le port sur les pods cibles vers lequel le service redirigera le trafic.
Maintenant, appliquons ce manifest en utilisant différentes méthodes.
Méthode 1 : Appliquer le fichier entier
C'est la manière la plus courante d'appliquer un manifest. Utilisez kubectl apply -f suivi du nom du fichier :
kubectl apply -f web-app.yaml
Cette commande créera à la fois le Deployment et le Service définis dans web-app.yaml. Vous devriez voir une sortie comme celle-ci :
deployment.apps/web-app created
service/web-service created
Méthode 2 : Appliquer depuis un répertoire
Vous pouvez appliquer tous les manifests d'un répertoire en une seule fois. Si vous avez plusieurs fichiers manifest dans le répertoire manifests, vous pouvez tous les appliquer en spécifiant le répertoire au lieu d'un fichier spécifique :
kubectl apply -f .
Le . représente le répertoire courant. kubectl recherchera les fichiers YAML dans ce répertoire et les appliquera tous. Ceci est utile lorsque vous avez organisé vos manifests en plusieurs fichiers au sein d'un répertoire.
Méthode 3 : Appliquer depuis une URL (Optionnel)
kubectl apply peut également appliquer des manifests directement depuis une URL. Ceci est utile pour déployer rapidement des applications ou des configurations d'exemple hébergées en ligne. Par exemple, vous pouvez déployer le déploiement maître Redis du dépôt d'exemples Kubernetes :
kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml
Cela téléchargera le manifest depuis l'URL et l'appliquera à votre cluster. Remarque : Soyez prudent lorsque vous appliquez des manifests provenant d'URL non fiables, car ils peuvent potentiellement modifier votre cluster.
Explorons quelques options supplémentaires pour kubectl apply.
Dry Run (Simulation)
Vous pouvez utiliser l'indicateur --dry-run=client pour simuler l'application d'un manifest sans apporter de modifications réelles au cluster. Ceci est utile pour vérifier si votre manifest est valide et pour voir quelles ressources seraient créées ou modifiées :
kubectl apply -f web-app.yaml --dry-run=client
Cette commande affichera ce qui serait créé ou modifié, mais n'appliquera pas réellement les modifications à votre cluster.
Sortie Verbeuse
Pour une sortie plus détaillée de kubectl apply, vous pouvez utiliser l'indicateur -v suivi d'un niveau de verbosité (par exemple, -v=7). Des niveaux de verbosité plus élevés fournissent des informations plus détaillées, ce qui peut être utile pour le débogage :
kubectl apply -f web-app.yaml -v=7
Cela affichera beaucoup plus d'informations sur les requêtes API effectuées et le traitement du manifest.
Vérifiez les ressources créées en appliquant web-app.yaml. Utilisez kubectl get deployments et kubectl get services pour lister les Deployments et les Services dans votre cluster :
## Lister les déploiements
kubectl get deployments
## Lister les services
kubectl get services
## Décrire le déploiement pour voir plus de détails
kubectl describe deployment web-app
Exemple de sortie pour kubectl get deployments :
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 3/3 3 3 3m33s
redis-master 0/1 1 0 23s
web-app 2/2 2 2 42s
Exemple de sortie pour kubectl get services :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 8m28s
web-service ClusterIP 10.106.220.33 <none> 80/TCP 46s
Notez que vous avez maintenant un Deployment web-app avec 2/2 répliques READY et un web-service de type ClusterIP.
Discutons brièvement de la différence entre la gestion déclarative et impérative dans Kubernetes, en particulier dans le contexte de kubectl apply et kubectl create.
kubectl apply : Utilise une approche déclarative. Vous définissez l'état souhaité dans vos fichiers manifest, et kubectl apply tente d'atteindre cet état. Si vous exécutez kubectl apply plusieurs fois avec le même manifest, Kubernetes n'apportera des modifications que s'il y a des différences entre l'état souhaité dans le manifest et l'état actuel dans le cluster. kubectl apply est généralement recommandé pour gérer les ressources Kubernetes car il est plus robuste et plus facile à gérer les changements au fil du temps. Il suit la configuration de vos ressources et permet des mises à jour incrémentielles.kubectl create : Utilise une approche impérative. Vous donnez directement des instructions à Kubernetes pour créer une ressource. Si vous essayez d'exécuter kubectl create pour une ressource qui existe déjà, cela entraînera généralement une erreur. kubectl create est moins flexible pour gérer les mises à jour et les changements par rapport à kubectl apply.
Dans la plupart des cas, en particulier pour la gestion des déploiements d'applications, kubectl apply est la méthode préférée et recommandée en raison de sa nature déclarative et de sa meilleure gestion des mises à jour et de la configuration.
