Was ist der Unterschied zwischen einem Pod und einer Bereitstellung?

Ich habe Pods mit erstellt, type:deploymentaber ich sehe, dass einige Dokumentationen verwendet werden type:pod, insbesondere die Dokumentation für Pods mit mehreren Containern :

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

Zum Erstellen von Pods kann ich jedoch nur einen Bereitstellungstyp verwenden :

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

Mir ist aufgefallen, dass in der Pod-Dokumentation Folgendes steht:

Der Befehl create kann verwendet werden, um einen Pod direkt zu erstellen, oder er kann einen oder mehrere Pods über eine Bereitstellung erstellen. Es wird dringend empfohlen, dass Sie eine Bereitstellung verwenden, um Ihre Pods zu erstellen. Es sucht nach ausgefallenen Pods und startet nach Bedarf neue Pods, um die angegebene Anzahl beizubehalten. Wenn Sie nicht möchten, dass eine Bereitstellung Ihren Pod überwacht (z. B. schreibt Ihr Pod nicht persistente Daten, die einen Neustart nicht überleben, oder Ihr Pod soll nur von kurzer Dauer sein), können Sie einen Pod direkt mit erstellen den Befehl create.

Hinweis: Wir empfehlen die Verwendung einer Bereitstellung zum Erstellen von Pods. Sie sollten die folgenden Anweisungen nur verwenden, wenn Sie keine Bereitstellung erstellen möchten.

Dies wirft jedoch die Frage auf, wofür kind:podgut ist. Können Sie Pods in einer Bereitstellung irgendwie referenzieren? Ich habe keinen Weg gesehen. Es sieht so aus, als würden Sie mit Pods einige zusätzliche Metadaten erhalten, aber keine der Bereitstellungsoptionen wie replicaoder eine Neustartrichtlinie. Was nützt ein Pod, der keine Daten speichert und einen Neustart überlebt? Ich denke, ich könnte auch einen Multi-Container-Pod mit einer Bereitstellung erstellen.

Sowohl Pod als auch Deployment sind vollwertige Objekte in der Kubernetes-API. Die Bereitstellung verwaltet das Erstellen von Pods mithilfe von ReplicaSets. Es läuft darauf hinaus, dass durch die Bereitstellung Pods mit Spezifikationen erstellt werden, die aus der Vorlage stammen. Es ist eher unwahrscheinlich, dass Sie jemals Pods direkt für einen Produktionsanwendungsfall erstellen müssen.

Radeks Antwort ist sehr gut, aber ich möchte aus meiner Erfahrung heraus einspringen, dass Sie fast nie ein Objekt mit dieser Art verwenden werden Pod verwenden werden , da dies in der Praxis keinen Sinn ergibt.

Da müssen Sie ein Deployment - Objekt - oder andere Kubernetes API - Objekte wie ein Replikations Controller oder replicaset - dass Bedürfnisse halten die Repliken (Hülsen) am Leben (die die Verwendung Kubernetes Art des Punktes ist).

Was Sie in der Praxis für eine typische Anwendung verwenden, sind:

1. Bereitstellungsobjekt (in dem Sie Ihren App-Container / Container angeben), das den Container Ihrer App mit einigen anderen Spezifikationen hostet.

2. Serviceobjekt (das ist wie ein Gruppierungsobjekt und gibt ihm eine sogenannte virtuelle IP (Cluster-IP) für podsdiejenigen, die eine bestimmte Bezeichnung haben - und dies podssind im Grunde die App-Container, die Sie mit der vorherigen Bereitstellung bereitgestellt haben ).

Sie müssen das Serviceobjekt haben , weil daspods vom Bereitstellungsobjekt stammende Objekt getötet, vergrößert und verkleinert werden kann und Sie sich nicht auf ihre IP-Adressen verlassen können, da sie nicht dauerhaft sind.

Sie brauchen also ein Objekt wie einen Dienst , der diese bietetpods eine stabile IP .

Ich wollte dir nur einen Kontext geben pods , damit Sie wissen, wie die Dinge zusammenarbeiten.

Hoffe das klärt ein paar Dinge für dich, vor nicht allzu langer Zeit war ich in deinen Schuhen :)

Kubernetes hat drei Objekttypen, die Sie kennen sollten:

• Pods - führt einen oder mehrere eng verwandte Container aus
• Dienste - Richtet das Netzwerk in einem Kubernetes-Cluster ein
• Bereitstellung - Verwaltet eine Reihe identischer Pods, um sicherzustellen, dass sie die richtige Konfiguration haben und die richtige Anzahl von ihnen vorhanden ist.

Pods:

• Führt einen einzelnen Satz von Containern aus
• Gut für einmalige Entwicklungszwecke
• Selten direkt in der Produktion eingesetzt

Einsatz:

• Führt eine Reihe identischer Pods aus
• Überwacht den Status jedes Pods und aktualisiert ihn nach Bedarf
• Gut für Entwickler
• Gut für die Produktion

Und ich würde anderen Antworten zustimmen, Pods vergessen und einfach Deployment verwenden. Warum? Schauen Sie sich den zweiten Aufzählungspunkt an, er überwacht den Status jedes Pods und wird bei Bedarf aktualisiert.

Anstatt mit Fehlermeldungen wie dieser zu kämpfen:

Verboten: Pod-Updates dürfen keine anderen Felder als ändern spec.containers[*].image

Überarbeiten Sie Ihren Pod einfach neu oder erstellen Sie ihn vollständig in einer Bereitstellung neu, die einen Pod erstellt, um das zu tun, was Sie tun müssen. Mit Deployment können Sie jede gewünschte Konfiguration ändern und müssen sich keine Sorgen mehr machen, dass diese Fehlermeldung angezeigt wird.

Pod ist eine Containerinstanz.

Das ist die Ausgabe von replicas: 3

Stellen Sie sich vor, Sie deploymentkönnen viele laufende Instanzen haben (Replikat).

//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 ist eine Sammlung von Containern und Grundobjekt von Kuberntes. Alle Behälter des Pods liegen im selben Knoten.

• Nicht für die Produktion geeignet
• Keine fortlaufenden Updates

Die Bereitstellung ist eine Art Controller in Kubernetes.

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

Durch die Bereitstellung wird ein ReplicaSet erstellt, das wiederum sicherstellt, dass CurrentReplicas immer mit den gewünschten Replicas identisch ist.

Vorteile:

• Sie können Ihre Änderungen mithilfe der Bereitstellung rollen und zurücksetzen
• Überwacht den Status jedes Pods
• Am besten für die Produktion geeignet
• Unterstützt fortlaufende Updates

Ich möchte einige Informationen aus dem Kubernetes In Action- Buch hinzufügen , damit Sie alle Bilder und Verbindungsbeziehungen zwischen Kubernetes-Ressourcen wie Pod, Deployment und ReplicationController (ReplicaSet) sehen können.

Pods

sind die grundlegende bereitstellbare Einheit in Kubernetes. In realen Anwendungsfällen möchten Sie jedoch, dass Ihre Bereitstellungen automatisch ausgeführt werden und ohne manuelle Eingriffe fehlerfrei bleiben. Zu diesem Zweck wird empfohlen, eine Bereitstellung zu verwenden , mit der unter der Haube ein ReplicaSet erstellt wird .

Ein ReplicaSet ist , wie der Name schon sagt, eine Reihe von Replikaten (Pods), die mit ihrem Revisionsverlauf verwaltet werden .

(ReplicaSet erweitert ein älteres Objekt namens ReplicationController - genau das gleiche, jedoch ohne den Revisionsverlauf.)

Ein ReplicaSet überwacht ständig die Liste der laufenden Pods und stellt sicher, dass die laufende Anzahl der Pods, die einer bestimmten Spezifikation entsprechen, immer mit der gewünschten Anzahl übereinstimmt.

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.

Eine Bereitstellung

ist eine übergeordnete Ressource, mit der Anwendungen bereitgestellt und deklarativ aktualisiert werden können.

Wenn Sie eine Bereitstellung erstellen , wird darunter eine ReplicaSet- Ressource erstellt (möglicherweise mehr davon). ReplicaSets replizieren und verwalten auch Pods. Wenn ein Deployment verwenden, werden die tatsächlichen Schoten erstellt und verwaltet durch die Bereitstellung s‘ ReplicaSets , nicht durch die Bereitstellung direkt

Lassen Sie uns darüber nachdenken, was passiert ist. Durch Ändern der Pod-Vorlage in Ihrer Bereitstellungsressource haben Sie Ihre App auf eine neuere Version aktualisiert - indem Sie ein einzelnes Feld geändert haben!

Führen Sie abschließend eine Bereitstellung zurück entweder auf die vorherige Version oder auf eine frühere Version zurück, die mit der Bereitstellungsressource so einfach ist.

Diese Bilder stammen ebenfalls aus dem Buch Kubernetes In Action .

Vermeiden Sie Pods und implementieren Sie stattdessen Bereitstellungen zum Verwalten von Containern, da Objekte der Art Pod bei einem Knotenausfall oder einer Pod-Beendigung nicht neu geplant (oder selbst geheilt) werden.

Eine Bereitstellung ist im Allgemeinen vorzuziehen, da sie ein ReplicaSet definiert, um sicherzustellen, dass die gewünschte Anzahl von Pods immer verfügbar ist, und eine Strategie zum Ersetzen von Pods wie RollingUpdate festlegt.

In Kubernetes sind Pods die kleinsten einsetzbaren Einheiten. Jedes Mal, wenn wir ein Kubernetes-Objekt wie Deployments, Replikatsätze, Statefulsets oder Daemonsets erstellen, wird ein Pod erstellt.

Wie oben erwähnt, erstellen Bereitstellungen Pods basierend auf dem gewünschten Status, der in Ihrem Bereitstellungsobjekt angegeben ist. Sie möchten beispielsweise 5 Replikate einer Anwendung, die Sie replicas: 5in Ihrem Bereitstellungsmanifest erwähnt haben. Jetzt ist der Deployment Controller dafür verantwortlich, 5 identische Replikate (nicht weniger, nicht mehr) einer bestimmten Anwendung mit allen Metadaten wie RBAC-Richtlinien, Netzwerkrichtlinien, Beschriftungen, Anmerkungen, Integritätsprüfungen, Ressourcenkontingenten, Verschmutzungen / Toleranzen und anderen zu erstellen und jedem Pod zuzuordnen es erstellt.

Es gibt einige Fälle, in denen Sie einen Pod erstellen möchten, z. B. wenn Sie ein Test-Sidecar ausführen, in dem Sie die Anwendung nicht für immer ausführen müssen, nicht mehrere Replikate benötigen und die Anwendung ausführen, wenn Sie sie ausführen möchten Koffer Pod ist geeignet. Dies ist beispielsweise helm testeine Pod-Definition, die einen Container mit einem bestimmten auszuführenden Befehl angibt.