Alternatives Kubernetes aux commandes Docker –
Docker fournit généralement la première introduction d’un développeur aux conteneurs. Kubernetes est une plate-forme d’orchestration qui résout les défis liés à l’exécution de conteneurs en production. Voici comment les commandes Docker correspondent à leurs homologues Kubernetes.
Vous ne pouvez pas utiliser le docker
CLI pour interagir avec les conteneurs exécutés dans Kubernetes. Kubernetes fournit sa propre interface de ligne de commande, kubectl
, pour vous aider à gérer votre cluster. Lisez notre guide pour démarrer avec kubectl
si vous ne connaissez pas l’outil.
Aucun des docker
les commandes ont le même nom dans kubectl
. Kubernetes expose les fonctionnalités à sa manière. Les charges de travail elles-mêmes sont fondamentalement différentes – Docker est conçu pour fonctionner avec un seul conteneur à la fois, tandis que Kubernetes permet l’orchestration de plusieurs réplicas.
Le premier point à apprécier est le changement de terminologie. Docker fait référence aux «conteneurs» tandis que Kubernetes utilise des «pods». Un pod peut exécuter un conteneur ou plusieurs réplicas gérés comme une seule unité. Ce détail mis à part, lorsque vous voyez «conteneur» dans Docker, vous devriez penser à un «pod» Kubernetes. Les termes seront utilisés de manière interchangeable pour le reste de cet article.
Sommaire
Obtenir des détails sur vos conteneurs
Dans Docker, vous utilisez docker ps -a
pour voir tous les conteneurs de votre machine.
L’équivalent Kubernetes le plus proche est kubectl get pods
.
La sortie des deux commandes est assez différente. Docker affiche plus d’informations sur la charge de travail exécutée par le conteneur.
Kubernetes fournira des détails sur l’image et la commande lors de l’utilisation du describe pod
commander. Vous devez transmettre le nom du pod. Cela donne des informations beaucoup plus détaillées, en utilisant une liste au lieu d’un tableau.
Exécution de commandes dans des conteneurs
Docker vous permet d’exécuter une commande dans un conteneur en cours d’exécution à l’aide de docker exec
.
L’équivalent Kubernetes est également appelé exec
. Utilisez le nom du pod Kubernetes au lieu du nom du conteneur Docker. La commande est spécifiée légèrement différemment – elle doit être séparée du nom du pod par un --
séquence.
Vous pouvez utiliser le -it
flags pour obtenir un accès interactif de la même manière que Docker. Ceci est un raccourci pour --stdin --tty
et doit être utilisé chaque fois que vous souhaitez lancer un shell dans un pod. Spécifiez le nom du shell, tel que bash
, comme commande.
Kubectl prend en charge le attach
commande lorsque vous souhaitez vous attacher à un processus dans un conteneur déjà en cours d’exécution. Cela fonctionne de la même manière que docker attach
mais tu devrais passer le -it
indicateurs si vous avez besoin d’un accès interactif.
Affichage des journaux de conteneur
Pour afficher les journaux d’un conteneur avec Docker, vous utilisez le docker logs
commander. Ajout du -f
switch « suivra » les journaux afin qu’ils soient diffusés en continu sur votre terminal.
Kubectl’s logs
La commande a la même syntaxe. Fournissez un nom de pod de la même manière que Docker accepte un nom de conteneur.
Docker et Kubernetes collectent les journaux à partir de la sortie standard et de l’erreur standard (stdout
/stderr
) flux de conteneurs en cours d’exécution. Kubernetes gère le redémarrage du conteneur différemment de Docker. Alors que dans Docker, un conteneur redémarré ajoute ses journaux aux journaux existants, Kubernetes crée un nouveau journal pour chaque exécution. Vous pouvez obtenir les journaux d’un conteneur remplacé en ajoutant le --previous
drapeau à la logs
commander.
Créer des conteneurs
Les conteneurs Docker sont créés avec le run
commander. Voici comment vous pouvez démarrer une nginx
serveur avec Docker:
docker run -d --name nginx --restart=always -p 80:80 nginx
Cela crée un conteneur en utilisant le nginx
l’image de base et la configure pour redémarrer automatiquement. Le serveur est lié au port HTTP par défaut 80.
Kubernetes vous oblige à penser à des abstractions de niveau supérieur lors de l’ajout de conteneurs à votre cluster. Au lieu d’exécuter un conteneur, vous créez un déploiement pour représenter votre charge de travail:
kubectl create deployment --image=nginx nginx
Cela créera un nginx
déploiement. Un pod démarre automatiquement; dans le pod, il y aura un conteneur exécutant le serveur Web.
La création d’un déploiement ne liera ses conteneurs à aucun port. Le serveur nouvellement créé n’est pas encore accessible. Les ports doivent être exposé par l’intermédiaire d’un un service. Les pods sont éphémères et peuvent contenir plusieurs conteneurs répliqués. Les services définissent une collection logique de pods et vous permettent de leur attribuer des ressources réseau telles qu’une adresse IP et un port.
Exposer le nginx
le déploiement sur le port 80 permettra d’accéder au serveur:
kubectl expose deployment nginx --port=80 --name nginx-http
Essayer d’accéder au port 80 sur l’adresse IP par défaut du cluster devrait maintenant vous diriger vers le nginx
serveur.
Kubectl ne prend pas directement en charge les autres docker run
des options telles que la création de volume et les montages de liaison. Les conteneurs qui nécessitent un stockage persistant devront avoir des volumes configurés manuellement via kubectl
commandes ou un manifeste de volume.
Suppression de conteneurs
Les conteneurs Docker sont supprimés à l’aide du docker rm
commande avec l’ID du conteneur.
Kubernetes ne vous permet pas de supprimer des conteneurs directement. Au lieu de cela, vous travaillez avec le déploiement qui a créé le pod. Utilisez le kubectl delete deployment
commande, en passant le nom du déploiement.
Docker vous permet de arrêter un conteneur au lieu de le retirer. Kubernetes a supprimé la prise en charge de cette action. La méthode recommandée pour suspendre temporairement un déploiement consiste à réduire son nombre de réplicas à 0. En l’absence de pod en cours d’exécution, la charge de travail est effectivement arrêtée.
kubectl scale --replicas=0 deployment/my-deployment
Lorsque vous êtes prêt à reprendre le déploiement, exécutez le scale
commande à nouveau. Définissez le nouveau nombre de réplicas sur 1
ou plus. L’utilisation de plus de réplicas peut augmenter la disponibilité de votre charge de travail.
Conclusion
Il n’y a pas de parallèles directs entre la CLI Docker et kubectl
. La plupart des commandes Kubernetes ont une syntaxe différente de celle de leurs homologues Docker. Vous devrez apprendre de nouveaux termes et options avant de pouvoir transférer les workflows basés sur Docker vers Kubernetes.
Dans de nombreux cas, il n’y a pas kubectl
alternative à une fonctionnalité CLI Docker. La fonctionnalité de Docker se concentre sur le concept de conteneur. Kubernetes prend cela et le place au centre d’un écosystème de ressources considérablement élargi.
Les conteneurs sont rarement traités isolément. Au lieu de cela, vous devrez travailler avec des ressources telles que des déploiements, des services et des jeux de réplicas. C’est pourquoi l’apprentissage de Kubernetes peut sembler difficile lorsqu’on l’aborde du point de vue d’un utilisateur de Docker.
Si vous connaissez les principes de base de Docker, la transition vers Kubernetes devrait néanmoins être relativement simple. La principale différence est que ce que Docker considère comme un conteneur est généralement accessible en tant que «pod» agrégé dans Kubernetes. Les pods sont créés par des «déploiements» qui représentent les charges de travail de votre cluster. En cas de doute, reportez-vous au kubectl
docs pour trouver une correspondance appropriée pour une commande Docker.