Von Docker-Containern zu Google Kubernetes

Dieser ist ein wenig theoretisch, aber bitte nehmen Sie ihn mit.

Derzeit habe ich einen Server, auf dem einige Docker-Container ausgeführt werden (4 oder 5, je nach Tag und Uhrzeit). Ich habe vor, eine weitere hinzuzufügen, genau wie die erste und vielleicht sogar eine dritte.

Meine Frage lautet nun: Sollte die Zeit kommen, in der ich 15 statt 5 Container verwalten muss, gibt es einen Vorteil bei der Verwendung von Google Kubernetes?

Gibt es auch einen "offiziellen" oder zumindest "endgültigen" Workflow für die Migration von Docker-Containern zu "Pods", der nativen Einheit von Kubernetes. Bevor Sie fragen, weiß ich, dass Schoten aus Behältern bestehen (manchmal sogar aus einem). Mein Hauptproblem hierbei ist, dass sich 'Dockerfiles' völlig von Pod-Konfigurationen unterscheiden.

Irgendwelche Ideen?

Sollte es an der Zeit sein, dass ich 15 statt 5 Container verwalten muss, gibt es einen Vorteil bei der Verwendung von Google Kubernetes?

Wenn Sie Container auf einem einzelnen Server mit dem Docker-Dämon und seiner Remote-API ausführen, klingt dies angemessen.

Wenn Sie Container auf mehr als einem Server ausführen müssen , sind Orchestrierungslösungen wie Kubernetes , Docker Swarm , Fleet , Mesos und Geard hilfreich.

Mein Hauptproblem hierbei ist, dass sich 'Dockerfiles' völlig von Pod-Konfigurationen unterscheiden.

Weil sie unterschiedliche Zwecke haben:

• Dockerfile Gibt an, wie ein Container-Image aus einem Quellenbaum erstellt wird
• pod.yaml Definiert, wie eine Reihe von nebeneinander angeordneten Containern (gemeinsam genutzter Netzwerk-Namespace und Volumes) auf einem der Knoten Ihres Clusters geplant werden soll (Image, Befehlszeile, Volumes, Port).

Sie können Pods als eine Möglichkeit sehen, eine Reihe von docker run --net=container:... -v ... -p ...Befehlen deklarativ anzugeben .

Gibt es auch einen "offiziellen" oder zumindest "endgültigen" Workflow für die Migration von Docker-Containern zu "Pods", der nativen Einheit von Kubernetes.

In kubernetes / contrib gibt es ein kleines Tool namens podex , mit dem Sie aus Bildmetadaten, die in der öffentlichen Registrierung gespeichert sind, ein Pod-Manifest generieren können.

$ go get github.com/GoogleCloudPlatform/kubernetes/contrib/podex
$ podex google/nodejs-hello
id: nodejs-hello
kind: Pod
apiVersion: v1beta1
desiredState:
  manifest:
    version: v1beta2
    containers:
    - name: nodejs-hello
      image: google/nodejs-hello
      ports:
      - name: nodejs-hello-tcp-8080
        containerPort: 8080

Die Antwort von @ proppy ist richtig: Einer arbeitet nur für einen einzelnen Server.

Ich hatte die gleiche anfängliche Reaktion, aber Sie können tatsächlich mehrere Dienste und Pods in einer einzigen Datei haben (getrennt durch ---). Auf diese Weise haben Sie im Allgemeinen immer noch 1 Service + 1 Pod pro Container, aber das ist nicht schlecht.

Sie müssen auch eine Reihe von Dingen mehr als in Docker-Compose benennen (manchmal denke ich, dass es mehr als notwendig ist). Sobald Sie gelernt haben, welcher Name wo wichtig ist, wird es Ihnen gut gehen und die Pflege der Dateien wird nicht viel schwieriger.

Die Bereitstellung ist IMO viel schwerer, wird aber wieder verteilt, und es kommt auch ein Deployment Pod-Typ, der Upgrades vereinfachen soll (derzeit als Beta-Erweiterung in Version 1.1).