Appliquer le manifeste YAML
Dans cette étape, vous allez explorer plus en détail la commande kubectl apply et apprendre différentes façons d'appliquer des manifestes Kubernetes. En vous appuyant sur les fichiers YAML de l'étape précédente, nous allons démontrer diverses techniques pour appliquer des manifestes.
Tout d'abord, assurez - vous que vous êtes dans le bon répertoire :
cd ~/project/k8s-manifests
Créons un nouveau sous - répertoire pour organiser davantage nos manifestes. Créez un répertoire nommé manifests et accédez - y :
mkdir -p manifests
cd manifests
Maintenant, créons un manifeste 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 manifeste définit deux ressources Kubernetes dans un seul fichier, séparées par ---. C'est une façon courante de regrouper des ressources liées. Analysons ce qui est nouveau :
- Plusieurs ressources 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 : Cela définit une ressource de type 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 auquel le service redirigera le trafic.
Maintenant, appliquons ce manifeste en utilisant différentes méthodes.
Méthode 1 : Appliquer le fichier entier
C'est la façon la plus courante d'appliquer un manifeste. 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 :
deployment.apps/web-app created
service/web-service created
Méthode 2 : Appliquer depuis un répertoire
Vous pouvez appliquer tous les manifestes d'un répertoire d'un coup. Si vous avez plusieurs fichiers de manifeste dans le répertoire manifests, vous pouvez les appliquer tous en spécifiant le répertoire au lieu d'un fichier spécifique :
kubectl apply -f.
Le . représente le répertoire actuel. kubectl cherchera les fichiers YAML dans ce répertoire et les appliquera tous. Cela est utile lorsque vous avez organisé vos manifestes en plusieurs fichiers au sein d'un répertoire.
Méthode 3 : Appliquer depuis une URL (Optionnel)
kubectl apply peut également appliquer des manifestes directement depuis une URL. Cela est utile pour déployer rapidement des applications d'exemple ou des configurations hébergées en ligne. Par exemple, vous pouvez déployer le déploiement Redis master depuis le dépôt d'exemples de Kubernetes :
kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/redis-master-deployment.yaml
Cela téléchargera le manifeste depuis l'URL et l'appliquera à votre cluster. Notez : Soyez prudent lorsque vous appliquez des manifestes depuis des URL non fiables car ils peuvent potentiellement modifier votre cluster.
Explorons quelques options supplémentaires pour kubectl apply.
Exécution simulée (Dry Run)
Vous pouvez utiliser le drapeau --dry - run=client pour simuler l'application d'un manifeste sans modifier réellement le cluster. Cela est utile pour vérifier si votre manifeste 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 elle n'appliquera pas réellement les modifications à votre cluster.
Sortie détaillée
Pour obtenir une sortie plus détaillée de kubectl apply, vous pouvez utiliser le drapeau -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 manifeste.
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éplicas 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, notamment 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 de manifeste, et kubectl apply tente d'atteindre cet état. Si vous exécutez kubectl apply plusieurs fois avec le même manifeste, Kubernetes ne fera des modifications que s'il y a des différences entre l'état souhaité dans le manifeste 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 modifications 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 instruisez directement Kubernetes de 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 modifications que kubectl apply.
Dans la plupart des cas, notamment pour gérer les 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.
