Quelle est la différence entre un pod et un déploiement?

J'ai créé des pods avec type:deploymentmais je vois que certaines documentations utilisent type:pod, plus spécifiquement 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 du pod indique:

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

Remarque: Nous vous recommandons d'utiliser un déploiement pour créer des modules. Vous ne devez utiliser les instructions ci-dessous que si vous ne souhaitez pas créer de déploiement.

Mais cela soulève la question de savoir à quoi kind:podbon? Pouvez-vous en quelque sorte référencer des pods dans un déploiement? Je n'ai vu aucun moyen. Il semble que ce que vous obtenez avec les pods soit des métadonnées supplémentaires, mais aucune des options de déploiement telles que replicaou une politique de redémarrage. À quoi sert un pod qui ne conserve pas les données, survit à un redémarrage? Je pense que je serais également en mesure de créer un pod multi-conteneurs avec un déploiement.

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

La réponse de Radek est très bonne, mais je voudrais m'appuyer sur mon expérience, vous n'utiliserez presque jamais un objet avec le pod de type , car cela n'a aucun sens dans la pratique.

Parce que vous avez besoin d'un objet de déploiement - ou d'autres objets de l'API Kubernetes comme un contrôleur de réplication ou un jeu de réplicas - qui doit garder les réplicas (pods) en vie (c'est un peu l'intérêt d'utiliser kubernetes).

Ce que vous utiliserez dans la pratique pour une application typique sont:

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

2. Objet de service (qui est comme un objet de regroupement et lui donne une IP dite virtuelle (IP de cluster) pour ceux podsqui ont une certaine étiquette - et ce podssont essentiellement les conteneurs d'applications que vous avez déployés avec l'ancien objet de déploiement ).

Vous devez avoir l' objet de service , car l' podsobjet de déploiement peut être tué, augmenté et réduit, 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 leur donne podsune IP stable.

Je voulais juste vous donner un peu de contexte podspour que vous sachiez comment les choses fonctionnent ensemble.

J'espère que cela vous éclaircira, il n'y a pas si longtemps j'étais à votre place :)

Kubernetes possède trois types d'objets que vous devez connaître:

• Pods - exécute un ou plusieurs conteneurs étroitement liés
• Services - configure la mise en réseau dans un cluster Kubernetes
• Déploiement - Maintient un ensemble de pods identiques, garantissant qu'ils ont la bonne configuration et que le bon nombre d'entre eux existent.

Pods:

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

Déploiement:

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

Et je suis d'accord avec d'autres réponses, oublie les pods et utilise simplement le déploiement. Pourquoi? Regardez le deuxième point, il surveille l'état de chaque module, en le mettant à jour si nécessaire.

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

Interdit: les mises à jour des modules ne peuvent pas modifier des champs autres que 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 quel élément de configuration que vous souhaitez et vous n'avez pas à vous soucier de voir ce message d'erreur.

Pod est une instance de conteneur.

C'est la sortie de replicas: 3

Pensez à un deploymentpeut avoir plusieurs instances en cours d'exécution (réplique).

//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

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

• Ne convient pas à la production
• Aucune mise à jour continue

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 CurrentReplicas sont toujours les mêmes que les désiréReplicas.

Avantages:

• Vous pouvez déployer et annuler vos modifications à l'aide du déploiement
• Surveille l'état de chaque pod
• Idéal pour la production
• Prend en charge les mises à jour continues

Je veux ajouter des informations de livre Kubernetes In Action , afin que vous puissiez voir toutes les images et les relations entre les ressources Kubernetes comme Pod, Deployment et ReplicationController (ReplicaSet)

Pods

sont l'unité déployable de base de Kubernetes. Mais dans les cas d'utilisation réels, vous souhaitez que vos déploiements restent opérationnels automatiquement et restent en bonne santé sans aucune intervention manuelle. Pour cela, l'approche recommandée consiste à utiliser un déploiement , qui sous le capot crée un ReplicaSet .

Un ReplicaSet , comme son nom l'indique, est un ensemble de répliques (Pods) conservées avec leur historique de révision .

(ReplicaSet étend un objet plus ancien appelé ReplicationController - qui est exactement le même mais sans l'historique de révision.)

Un ReplicaSet surveille en permanence la liste des pods en cours d'exécution et s'assure que le nombre de pods correspondant à une certaine spécification correspond toujours au nombre souhaité.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

Un déploiement

est une ressource de niveau supérieur destinée à déployer des applications et à les mettre à jour de manière déclarative.

Lorsque vous créez un déploiement , une ressource ReplicaSet est créée en dessous (éventuellement plus). Les ReplicaSets répliquent et gèrent également les pods. Lors de l' utilisation d' un déploiement, les gousses réels sont créés et gérés par le déploiement de » les ReplicaSets , non par le déploiement directement

Réfléchissons à ce qui s'est passé. En modifiant le modèle de pod dans votre ressource de déploiement, vous avez mis à jour votre application vers une version plus récente, en modifiant un seul champ!

Enfin, annulez un déploiement vers la révision précédente ou vers une révision antérieure si simple avec la ressource de déploiement.

Ces images sont également extraites du livre Kubernetes In Action .

Essayez d'éviter les pods et implémentez plutôt les déploiements pour gérer les conteneurs, car les objets de type pod ne seront pas reprogrammés (ou auto-réparés) en cas de défaillance d'un nœud ou de terminaison 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 pour remplacer les pods, telle que RollingUpdate.

Dans kubernetes, les pods sont les plus petites unités déployables. Chaque fois que nous créons un objet kubernetes comme les déploiements, les jeux de réplicas, les jeux avec état, les jeux de démons, il crée un pod.

Comme mentionné ci-dessus, les déploiements créent des modules en fonction de l'état souhaité mentionné dans votre objet de déploiement. Donc, par exemple, vous voulez 5 répliques d'une application, vous avez mentionnéreplicas: 5 dans votre manifeste de déploiement. Désormais, le contrôleur de déploiement est chargé de créer 5 répliques identiques (ni moins, ni plus) de l'application donnée avec toutes les métadonnées telles que la stratégie RBAC, la stratégie de réseau, les étiquettes, les annotations, le contrôle d'intégrité, les quotas de ressources, les souillures / tolérances et autres et les associer à chaque pod. ça crée.

Il y a des cas où vous voulez créer un pod, par exemple si vous exécutez un side-car de test où vous n'avez pas besoin d'exécuter l'application pour toujours, vous n'avez pas besoin de plusieurs répliques et vous exécutez l'application lorsque vous souhaitez l'exécuter le boîtier du boîtier convient. Par exemple helm test, qui est une définition de pod qui spécifie un conteneur avec une commande donnée à exécuter.