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

Question

J'ai été la création de gousses avec type:deployment mais je vois que certains documentation utilise type:pod, plus précisément de la documentation pour le multi-conteneur pods:

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

Mais pour créer les gousses je peux 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 pod dit:

La commande de création peut être utilisé pour créer un pod directement, ou il peut créer un pod ou de gousses par le biais d'un Déploiement. Il est fortement recommandé l'utilisation d'un Déploiement pour créer votre gousses. Il le regarde d'un échec les gousses et le démarrage de nouveaux groupes afin de maintenir le spécifiée numéro. Si vous ne voulez pas d'un Déploiement de surveiller votre pod (par exemple, votre pod est l'écriture de données non persistantes qui ne survivra pas à un redémarrage, ou votre module est destiné à être de très courte durée), vous pouvez créer un pod directement avec la commande create.

Remarque: Nous recommandons l'utilisation d'un Déploiement de créer des gousses. Vous devez utiliser les instructions ci-dessous uniquement si vous ne souhaitez pas créer un Déploiement.

Mais cela soulève la question de savoir ce qu' kind:pod est bon pour? Pouvez-vous en quelque sorte de référence des gousses dans un déploiement? Je n'ai pas vu un. Il ressemble à ce que vous obtenez avec des gousses est certains de métadonnées supplémentaires, mais aucune des options de déploiement tels que replica ou un redémarrage de la politique. A quoi bon un pod qui ne persistent données, survit à un redémarrage? Je pense que je serais capable de créer un multi-conteneur pod avec un déploiement.

Answer 1

Radek la réponse est très bonne, mais je tiens à la hauteur de mon expérience, vous aurez presque jamais utiliser un objet avec le type pod, parce que ça n'a aucun sens dans la pratique.

Parce que vous avez besoin d'un déploiement de l'objet ou d'autres Kubernetes les objets de l'API comme une réplication du contrôleur ou replicaset - qui doit suivre les répliques (gousses) vivant (qui est le point de l'utilisation de kubernetes).

Ce que vous allez utiliser dans la pratique pour une application typiques sont:

1. L'objet de déploiement (où vous pourrez spécifier vos applications de conteneurs/conteneurs) qui sera l'hôte de votre application conteneur avec quelques autres spécifications.

2. Objet du Service (c'est comme un objet de regroupement et lui donne un soi-disant virtuel IP (IP de cluster) pour l' pods qui ont une certaine étiquette - et ceux - pods sont fondamentalement les conteneurs d'applications que vous avez déployé avec l'ancien déploiement de l'objet).

Vous avez besoin du service objet parce que l' pods depuis le déploiement de l'objet peuvent être tués, mis à l'échelle en haut et en bas, et vous ne pouvez pas compter sur leurs adresses IP, car ils ne seront pas persistant.

Si vous avez besoin d'un objet, comme un service, qui donne à ceux - pods stable IP.

Voulais juste vous donner le contexte autour de pods, de sorte que vous savez comment les choses fonctionnent ensemble.

J'espère que efface un peu les choses pour vous, il n'ya pas longtemps j'ai été dans vos chaussures :)

Answer 2

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.

Answer 3

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 résiliation 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.

Answer 4

Dans kubernetes les Gousses sont les plus petites unités projetables. Chaque fois que nous créons un kubernetes objet, comme les Déploiements, réplique-ensembles, statefulsets, daemonsets il crée pod.

Comme mentionné ci-dessus déploiements de créer des gousses basé sur l'état souhaité mentionné dans votre déploiement de l'objet. Ainsi, par exemple, vous souhaitez que 5 répliques d'une application, vous avez mentionné replicas: 5 dans votre manifeste de déploiement. Maintenant déploiement contrôleur est responsable de la création d'5 répliques identiques (pas moins, pas plus) de l'application avec toutes les métadonnées comme RBAC de la politique, politique des réseaux, des étiquettes, des annotations, bilan de santé, de ressources quotas, souillure/autorisations et les autres et de s'associer avec chaque gousses qu'il crée.

Il y a certains cas où vous veut créer pod, par exemple, si vous exécutez un test de sidecar où vous n'avez pas besoin de lancer l'application pour toujours, vous n'avez pas besoin de plusieurs répliques, et que vous exécutez l'application lorsque vous souhaite à exécuter dans ce cas pod est adapté. Par exemple helm test, ce qui est une gousse définition qui spécifie un conteneur avec une commande à exécuter.