web-dev-qa-db-fra.com

En kubernetes, quelle est la différence entre un pod et un déploiement?

J'ai créé des pods avec type:deployment mais je constate que certains documents utilisent type:pod, plus précisément la documentation des pods multi-conteneurs :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

Mais pour créer des pods, je peux simplement utiliser un type de déploiement :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

J'ai remarqué que la documentation de pod disait:

La commande create peut être utilisée pour créer directement un pod, ou elle peut créer un ou plusieurs pods via un déploiement. Il est fortement recommandé que vous utilisez un déploiement pour créer vos pods. Il surveille les échecs pods et démarrera de nouveaux pods si nécessaire pour maintenir le spécifié. nombre. Si vous ne souhaitez pas qu'un déploiement surveille votre pod (par exemple, votre Écrit des données non persistantes qui ne survivront pas à un redémarrage, ou Votre pod est destiné à être de très courte durée), vous peut créer un pod directement avec la commande create.

Remarque: nous vous recommandons d'utiliser un déploiement pour créer des pods. Tu devrais utiliser les instructions ci-dessous que si vous ne voulez pas créer de déploiement.

Mais cela pose la question de savoir à quoi sert kind:pod? Pouvez-vous en quelque sorte référencer des pods dans un déploiement? Je n'ai vu aucun moyen. Il semble que vous obtenez avec les pods quelques métadonnées supplémentaires, mais aucune des options de déploiement telles que replica ou une stratégie de redémarrage. A quoi bon un pod qui ne conserve pas de données, survit à un redémarrage? Je pense que je serais capable de créer un pod multi-conteneurs avec un déploiement également.

kubernetes
97
Bjorn Tipling

Pod et Deployment sont des objets à part entière dans l'API Kubernetes. Le déploiement gère la création de pods à l'aide de ReplicaSets. Cela revient à dire que le déploiement créera des pods avec des spécifications extraites du modèle. Il est plutôt peu probable que vous ayez besoin de créer des pods directement pour un cas d'utilisation en production.

80
Radek 'Goblin' Pieczonka

La réponse de Radek est très bonne, mais je voudrais ajouter de mon expérience, vous n'utiliserez presque jamais un objet avec le genrepod, car cela ne pas de sens dans la pratique. 

Parce que vous avez besoin d’un objet déploiement - ou d’autres objets de l’API Kubernetes, comme un contrôleur de réplication ou réplicaset - qui doit conserver le répliquespods) en vie (c’est un peu l’intérêt d’utiliser des kubernetes).

Ce que vous utiliserez en pratique pour une application typique sont:

  1. Objet de déploiement (où vous spécifierez votre conteneur/conteneurs d'applications) qui hébergera le conteneur de votre application avec d'autres spécifications.

  2. Objet de service (qui ressemble à un objet de regroupement et lui donne une adresse IP virtuelle (adresse IP du cluster) pour les pods qui ont une certaine étiquette - et ces pods sont essentiellement les conteneurs d'applications que vous avez déployés avec ancien objet déploiement.

Vous devez disposer de l'objet service, car la variable pods de l'objet de déploiement peut être supprimée, augmentée ou réduite, et vous ne pouvez pas vous fier à leurs adresses IP, car elles ne seront pas persistantes.

Vous avez donc besoin d’un objet comme un service, qui donne à ces pods une adresse IP stable.

Je voulais juste vous donner un peu de contexte autour de pods, afin que vous sachiez comment les choses fonctionnent ensemble.

J'espère que ça efface quelques points pour vous, il n'y a pas si longtemps j'étais à votre place :)

115
Tomislav Mikulin

Kubernetes a trois types O bject que vous devriez connaître:

  • Pods - exécute un ou plusieurs conteneurs étroitement liés
  • Services - configure la mise en réseau dans un cluster Kubernetes
  • Deployment - Maintient un ensemble de pods identiques, en s'assurant qu'ils ont la configuration correcte et que leur nombre correct existe.

Pods:

  • Exécute un seul ensemble de conteneurs
  • Bon à des fins de développement ponctuelles
  • Rarement utilisé directement dans la production

Déploiement:

  • Exécute un ensemble de cosses identiques
  • Surveille l'état de chaque pod, en mettant à jour si nécessaire
  • Bon pour dev
  • Bon pour la production

Et je suis d’accord avec d’autres réponses, oubliez les Pods et utilisez simplement le déploiement. Pourquoi? Regardez le deuxième point, il surveille l’état de chaque module et se met à jour si nécessaire.

Ainsi, au lieu de lutter avec des messages d'erreur tels que celui-ci:

Forbidden: pod updates may not change fields other than spec.containers[*].image

Il suffit donc de refactoriser ou de recréer complètement votre pod dans un déploiement qui crée un pod pour faire ce que vous avez besoin de faire. Avec le déploiement, vous pouvez modifier n’importe quelle partie de la configuration que vous souhaitez et vous n’aurez plus à vous soucier de ce message d’erreur.

8
Daniel

Pod est une collection de conteneurs et objet de base de Kuberntes. Tous les conteneurs de pod se trouvent dans le même noeud.

  • Ne convient pas à la production
  • Pas de mises à jour roulantes

Le déploiement est une sorte de contrôleur dans Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Le déploiement crée un ReplicaSet qui, à son tour, garantit que les copies souhaitées sont toujours identiques à celles de CurrentReplicas.

Avantages:

  • Vous pouvez déployer et annuler vos modifications à l'aide du déploiement
  • Surveille l'état de chaque pod
  • Mieux adapté à la production
  • Prise en charge des mises à jour roulantes
3
Nikhil Kumar

Pod est une instance de conteneur.

 enter image description here 

C'est la sortie de replicas: 3

Penser à une deployment peut avoir plusieurs instances en cours d'exécution (réplica).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: Tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: Tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: Tomcat
    spec:
      containers:
      - name: Tomcat
        image: Tomcat:9.0
        ports:
        - containerPort: 8080
2
serkan

Dans kubernetes, les pods sont les plus petites unités déployables. Chaque fois que nous créons un objet kubernetes comme des déploiements, des ensembles de réplicas, des états, des daemonsets, il crée un pod.

Comme mentionné ci-dessus, les déploiements créent des pods basés sur l'état souhaité mentionné dans votre objet de déploiement. Par exemple, si vous voulez 5 répliques d’une application, vous avez mentionné replicas: 5 dans votre manifeste de déploiement. Maintenant, le contrôleur de déploiement est responsable de la création de 5 réplicas identiques (pas moins, pas plus) d'une application donnée avec toutes les métadonnées telles que la stratégie RBAC, la stratégie réseau, les étiquettes, les annotations, le bilan de santé, les quotas de ressources, les modifications/tolérances et autres, et de les associer à chaque pod. ça crée.

Dans certains cas, vous souhaitez créer un pod, par exemple, si vous exécutez une console de test où vous n'avez pas besoin d'exécuter l'application à l'infini, vous n'avez pas besoin de plusieurs réplicas et vous exécutez l'application lorsque vous souhaitez l'exécuter dans cette application. cas pod est approprié. Par exemple, helm test, qui est une définition de pod qui spécifie un conteneur avec une commande donnée à exécuter.

1
Balkrishna

Essayez d'éviter les pods et implémentez plutôt des déploiements pour gérer les conteneurs en tant qu'objets de type. Pod ne sera pas replanifié (ni auto guéri) en cas de défaillance d'un nœud ou de fin de pod.

Un déploiement est généralement préférable car il définit un ReplicaSet pour garantir que le nombre souhaité de pods est toujours disponible et spécifie une stratégie de remplacement des pods, telle que RollingUpdate. 

0
maelga