webentwicklung-frage-antwort-db.com.de

Was ist in kubernetes der Unterschied zwischen einer Pod und einer Bereitstellung?

Ich habe Pods mit type:deployment erstellt, aber ich sehe, dass einige Dokumentationen type:pod verwenden, genauer gesagt die Dokumentation für Mehrcontainer-Pods :

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

Um Pods zu erstellen, kann ich einfach einen Bereitstellungstyp verwenden:

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

Mir ist aufgefallen, dass die Pod-Dokumentation Folgendes sagt:

Mit dem Befehl create können Sie einen Pod direkt erstellen oder Erstellen Sie einen Pod oder Pods durch eine Bereitstellung. Es wird dringend empfohlen dass Sie eine Bereitstellung verwenden, um Ihre Pods zu erstellen. Es wacht auf fehlgeschlagene pods und startet bei Bedarf neue pods, um die angegebene Nummer. Wenn Sie nicht möchten, dass eine Bereitstellung Ihren Pod überwacht, schreibt Ihr Pod nicht persistente Daten, die einen Neustart nicht überstehen, oder . Ihr Pod soll sehr kurzlebig sein kann eine Pod .__ erstellen. direkt mit dem Befehl create.

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

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

97
Bjorn Tipling

Sowohl der Pod als auch die Bereitstellung sind vollwertige Objekte in der Kubernetes-API. Die Bereitstellung verwaltet das Erstellen von Pods mithilfe von ReplicaSets. Es kommt darauf an, dass bei der Bereitstellung Pods erstellt werden, deren Spezifikationen aus der Vorlage übernommen werden. Es ist eher unwahrscheinlich, dass Sie Pods direkt für einen Produktionsanwendungsfall erstellen müssen.

Radeks Antwort ist sehr gut, aber ich würde gerne aus meiner Erfahrung heraus sagen, dass Sie fast nie ein object mit der kindpod verwenden werden, da dies nicht der Fall ist Das macht in der Praxis keinen Sinn. 

Weil Sie ein Deployment -Objekt benötigen - oder andere Kubernetes-API-Objekte wie ein Replikationscontroller oder Replicaset -, die die Replikate ( pods) lebendig (das ist der Punkt, in dem kubernetes verwendet werden).

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

  1. Bereitstellungsobjekt (Hier geben Sie den Container/die Container für Ihre Apps an), der den Container Ihrer App mit einigen anderen Spezifikationen hostet.

  2. Service object (das ist wie ein Gruppierungsobjekt und gibt ihm eine sogenannte virtuelle IP (Cluster-IP) für die pods, die eine bestimmte Bezeichnung hat - und diese pods sind im Grunde die App-Container, die Sie mit bereitstellen ehemaliges Bereitstellung Objekt).

Sie benötigen das Service -Objekt, da die pods des Implementierungsobjekts abgebrochen werden kann, die Größe nach oben und nach unten skaliert werden kann und Sie sich nicht auf ihre IP-Adressen verlassen können, da sie nicht dauerhaft sind.

Sie benötigen also ein Objekt wie ein Dienst, das diesen pods eine stabile IP gibt.

Ich wollte Ihnen nur einen Zusammenhang zu pods geben, damit Sie wissen, wie die Dinge zusammenarbeiten.

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

115

Kubernetes hat drei O Objekttypen die Sie kennen sollten über:

  • Pods - führt einen oder mehrere eng verwandte Container aus
  • Dienste - richten die Vernetzung in einem Kubernetes-Cluster ein
  • Bereitstellung - Verwaltet eine Reihe identischer Pods, um sicherzustellen, dass sie die richtige Konfiguration haben und dass 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

Bereitstellung:

  • 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 die Bereitstellung verwenden. Warum? Wenn Sie sich den zweiten Punkt ansehen, wird der Status jedes Pods überwacht und bei Bedarf aktualisiert.

Also, anstatt mit Fehlermeldungen wie dieser zu kämpfen:

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

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

8
Daniel

Pod ist eine Sammlung von Containern und Basisobjekten von Kuberntes. Alle Behälter der Hülse liegen in demselben 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 "desiredReplicas" immer mit "CurrentReplicas" identisch ist.

Vorteile:

  • Sie können Ihre Änderungen mithilfe der Bereitstellung implementieren und zurücksetzen
  • Überwacht den Status jedes Pods
  • Bestens für die Produktion geeignet
  • Unterstützt fortlaufende Updates
3
Nikhil Kumar

Pod ist Containerinstanz.

 enter image description here 

Das ist die Ausgabe von replicas: 3

Stellen Sie sich eine deployment vor, die viele laufende Instanzen (Replikate) haben kann.

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

In kubernetes sind Pods die kleinsten einsetzbaren Einheiten. Jedes Mal, wenn wir ein kubernetes Objekt wie Deployments, Replica-Sets, 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. Wenn Sie beispielsweise 5 Replikate einer Anwendung benötigen, haben Sie in Ihrem Bereitstellungsmanifest replicas: 5 angegeben. Der Deployment Controller ist jetzt dafür verantwortlich, 5 identische Replikate (nicht weniger und nicht mehr) einer bestimmten Anwendung mit allen Metadaten wie RBAC-Richtlinien, Netzwerkrichtlinien, Labels, Anmerkungen, Integritätsprüfungen, Ressourcenkontingenten, Verschmutzungen/Toleranzen usw. zu erstellen und den einzelnen Pods zuzuordnen es erstellt.

In einigen Fällen möchten Sie einen Pod erstellen. Wenn Sie beispielsweise einen Test-Sidecar ausführen, bei dem die Anwendung nicht für immer ausgeführt werden muss, nicht mehrere Replikate erforderlich sind und wenn Sie die Anwendung in diesem Fall ausführen möchten, müssen Sie mehrere Replikate ausführen Case Pod ist geeignet. Zum Beispiel helm test, eine Pod-Definition, die einen Container mit einem bestimmten auszuführenden Befehl angibt.

1
Balkrishna

Vermeiden Sie Pods und implementieren Sie stattdessen Bereitstellungen zum Verwalten von Containern als Objekte der Art. Pod wird im Falle eines Knotenausfalls oder eines Pod-Abbruchs nicht neu geplant (oder selbst geheilt).

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 angibt, beispielsweise RollingUpdate. 

0
maelga