Yushiro FURUKAWA
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
331cc6fee0
commit
99619d3414
@@ -15,7 +15,7 @@ Im Abschnitt Konzepte erfahren Sie mehr über die Teile des Kubernetes-Systems u
|
||||
|
||||
## Überblick
|
||||
|
||||
Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben:
|
||||
Um mit Kubernetes zu arbeiten, verwenden Sie *Kubernetes-API-Objekte*, um den *gewünschten Status Ihres Clusters* zu beschreiben:
|
||||
welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Containerimages sie verwenden, die Anzahl der Replikate, welche Netzwerk- und Festplattenressourcen Sie zur Verfügung stellen möchten, und vieles mehr. Sie legen den gewünschten Status fest, indem Sie Objekte mithilfe der Kubernetes-API erstellen, normalerweise über die Befehlszeilenschnittstelle `kubectl`. Sie können die Kubernetes-API auch direkt verwenden, um mit dem Cluster zu interagieren und den gewünschten Status festzulegen oder zu ändern.
|
||||
|
||||
Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
|
||||
@@ -27,7 +27,7 @@ Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Contr
|
||||
|
||||
## Kubernetes Objects
|
||||
|
||||
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: implementierte containerisierte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
|
||||
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: implementierte containerisierte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
|
||||
|
||||
Die grundlegenden Objekte von Kubernetes umfassen:
|
||||
|
||||
|
||||
@@ -95,7 +95,7 @@ In diesem neuen Modell initialisiert das Kubelet einen Knoten ohne cloudspezifis
|
||||
|
||||
Der Cloud Controller Manager verwendet die Go Schnittstellen, um Implementierungen aus jeder Cloud einzubinden. Konkret verwendet dieser das CloudProvider Interface, das [hier](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62) definiert ist.
|
||||
|
||||
Die Implementierung der vier oben genannten geteiltent Controllern und einigen Scaffolding sowie die gemeinsame CloudProvider Schnittstelle bleiben im Kubernetes Kern. Cloud Provider spezifische Implementierungen werden außerhalb des Kerns aufgebaut und implementieren im Kern definierte Schnittstellen.
|
||||
Die Implementierung der vier oben genannten geteiltent Controllern und einigen Scaffolding sowie die gemeinsame CloudProvider Schnittstelle bleiben im Kubernetes Kern. Cloud Provider spezifische Implementierungen werden außerhalb des Kerns aufgebaut und implementieren im Kern definierte Schnittstellen.
|
||||
|
||||
Weitere Informationen zur Entwicklung von Plugins findest du im Bereich [Entwickeln von Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ weight: 20
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
|
||||
Dieses Dokument katalogisiert die Kommunikationspfade zwischen dem Master (eigentlich dem Apiserver) und des Kubernetes-Clusters.
|
||||
Die Absicht besteht darin, Benutzern die Möglichkeit zu geben, ihre Installation so anzupassen, dass die Netzwerkkonfiguration so abgesichert wird, dass der Cluster in einem nicht vertrauenswürdigen Netzwerk (oder mit vollständig öffentlichen IP-Adressen eines Cloud-Providers) ausgeführt werden kann.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -34,7 +34,7 @@ Der Standardbetriebsmodus für Verbindungen vom Cluster (Knoten und Pods, die au
|
||||
## Master zum Cluster
|
||||
|
||||
Es gibt zwei primäre Kommunikationspfade vom Master (Apiserver) zum Cluster.
|
||||
Der erste ist vom Apiserver bis zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
|
||||
Der erste ist vom Apiserver bis zum Kubelet-Prozess, der auf jedem Node im Cluster ausgeführt wird.
|
||||
Der zweite ist vom Apiserver zu einem beliebigen Node, Pod oder Dienst über die Proxy-Funktionalität des Apiservers.
|
||||
|
||||
### Apiserver zum kubelet
|
||||
|
||||
@@ -8,9 +8,9 @@ weight: 10
|
||||
|
||||
Ein Knoten (Node in Englisch) ist eine Arbeitsmaschine in Kubernetes, früher als `minion` bekannt. Ein Node
|
||||
kann je nach Cluster eine VM oder eine physische Maschine sein. Jeder Node enthält
|
||||
die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
|
||||
und wird von den Master-Komponenten verwaltet.
|
||||
Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
|
||||
die für den Betrieb von [Pods](/docs/concepts/workloads/pods/pod/) notwendigen Dienste
|
||||
und wird von den Master-Komponenten verwaltet.
|
||||
Die Dienste auf einem Node umfassen die [Container Runtime](/docs/concepts/overview/components/#node-components), das Kubelet und den Kube-Proxy.
|
||||
Weitere Informationen finden Sie im Abschnitt Kubernetes Node in der Architekturdesign-Dokumentation.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -64,13 +64,13 @@ Der Zustand eines Nodes wird als JSON-Objekt dargestellt. Die folgende Antwort b
|
||||
|
||||
Wenn der Status der `Ready`-Bedingung `Unknown` oder `False` länger als der `pod-eviction-timeout` bleibt, wird ein Parameter an den [kube-controller-manager](/docs/admin/kube-controller-manager/) übergeben und alle Pods auf dem Node werden vom Node Controller gelöscht.
|
||||
|
||||
Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**.
|
||||
In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren.
|
||||
Die voreingestellte Zeit vor der Entfernung beträgt **fünf Minuten**.
|
||||
In einigen Fällen, in denen der Node nicht erreichbar ist, kann der Apiserver nicht mit dem Kubelet auf dem Node kommunizieren.
|
||||
Die Entscheidung, die Pods zu löschen, kann dem Kublet erst mitgeteilt werden, wenn die Kommunikation mit dem Apiserver wiederhergestellt ist.
|
||||
In der Zwischenzeit können Pods, deren Löschen geplant ist, weiterhin auf dem unzugänglichen Node laufen.
|
||||
|
||||
|
||||
In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.
|
||||
In Versionen von Kubernetes vor 1.5 würde der Node Controller das Löschen dieser unerreichbaren Pods vom Apiserver [erzwingen](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). In Version 1.5 und höher erzwingt der Node Controller jedoch keine Pod Löschung, bis bestätigt wird, dass sie nicht mehr im Cluster ausgeführt werden. Pods die auf einem unzugänglichen Node laufen sind eventuell in einem einem `Terminating` oder `Unkown` Status. In Fällen, in denen Kubernetes nicht aus der zugrunde liegenden Infrastruktur schließen kann, ob ein Node einen Cluster dauerhaft verlassen hat, muss der Clusteradministrator den Node möglicherweise manuell löschen.
|
||||
Das Löschen des Kubernetes-Nodeobjekts bewirkt, dass alle auf dem Node ausgeführten Pod-Objekte gelöscht und deren Namen freigegeben werden.
|
||||
|
||||
In Version 1.12 wurde die Funktion `TaintNodesByCondition` als Beta-Version eingeführt, die es dem Node-Lebenszyklus-Controller ermöglicht, automatisch [Markierungen](/docs/concepts/configuration/taint-and-toleration/) (*taints* in Englisch) zu erstellen, die Bedingungen darstellen.
|
||||
@@ -79,13 +79,13 @@ Ebenso ignoriert der Scheduler die Bedingungen, wenn er einen Node berücksichti
|
||||
|
||||
Anwender können jetzt zwischen dem alten Scheduling-Modell und einem neuen, flexibleren Scheduling-Modell wählen.
|
||||
|
||||
Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant.
|
||||
Ein Pod, der keine Toleranzen aufweist, wird gemäß dem alten Modell geplant.
|
||||
Aber ein Pod, die die Taints eines bestimmten Node toleriert, kann auf diesem Node geplant werden.
|
||||
|
||||
{{< caution >}}
|
||||
Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit,
|
||||
in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht.
|
||||
Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl
|
||||
Wenn Sie diese Funktion aktivieren, entsteht eine kleine Verzögerung zwischen der Zeit,
|
||||
in der eine Bedingung beobachtet wird, und der Zeit, in der ein Taint entsteht.
|
||||
Diese Verzögerung ist in der Regel kürzer als eine Sekunde, aber sie kann die Anzahl
|
||||
der Pods erhöhen, die erfolgreich geplant, aber vom Kubelet abgelehnt werden.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -104,7 +104,7 @@ Die Informationen werden von Kubelet vom Node gesammelt.
|
||||
|
||||
Im Gegensatz zu [Pods](/docs/concepts/workloads/pods/pod/) und [Services](/docs/concepts/services-networking/service/),
|
||||
ein Node wird nicht von Kubernetes erstellt: Er wird extern von Cloud-Anbietern wie Google Compute Engine erstellt oder ist in Ihrem Pool physischer oder virtueller Maschinen vorhanden.
|
||||
Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt.
|
||||
Wenn Kubernetes also einen Node erstellt, wird ein Objekt erstellt, das den Node darstellt.
|
||||
Nach der Erstellung überprüft Kubernetes, ob der Node gültig ist oder nicht.
|
||||
|
||||
Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
|
||||
@@ -123,7 +123,7 @@ Wenn Sie beispielsweise versuchen, einen Node aus folgendem Inhalt zu erstellen:
|
||||
```
|
||||
|
||||
|
||||
Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
|
||||
Kubernetes erstellt intern ein Node-Oject (die Darstellung) und validiert den Node durch Zustandsprüfung basierend auf dem Feld `metadata.name`.
|
||||
Wenn der Node gültig ist, d.h. wenn alle notwendigen Dienste ausgeführt werden, ist er berechtigt, einen Pod auszuführen.
|
||||
Andernfalls wird er für alle Clusteraktivitäten ignoriert, bis er gültig wird.
|
||||
|
||||
@@ -140,45 +140,45 @@ Aktuell gibt es drei Komponenten, die mit dem Kubernetes Node-Interface interagi
|
||||
|
||||
Der Node Controller ist eine Kubernetes-Master-Komponente, die verschiedene Aspekte von Nodes verwaltet.
|
||||
|
||||
Der Node Controller hat mehrere Rollen im Leben eines Nodes.
|
||||
Der Node Controller hat mehrere Rollen im Leben eines Nodes.
|
||||
Der erste ist die Zuordnung eines CIDR-Blocks zu dem Node, wenn er registriert ist (sofern die CIDR-Zuweisung aktiviert ist).
|
||||
|
||||
Die zweite ist, die interne Node-Liste des Node Controllers mit der Liste der verfügbaren Computer des Cloud-Anbieters auf dem neuesten Stand zu halten.
|
||||
Wenn ein Node in einer Cloud-Umgebung ausgeführt wird und sich in einem schlechten Zustand befindet, fragt der Node Controller den Cloud-Anbieter, ob die virtuelle Maschine für diesen Node noch verfügbar ist. Wenn nicht, löscht der Node Controller den Node aus seiner Node-Liste.
|
||||
|
||||
Der dritte ist die Überwachung des Zustands der Nodes. Der Node Controller ist dafür verantwortlich,
|
||||
die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen).
|
||||
die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen).
|
||||
Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-period` Sekunden.
|
||||
|
||||
|
||||
In Versionen von Kubernetes vor 1.13 ist NodeStatus der Herzschlag des Nodes.
|
||||
Ab Kubernetes 1.13 wird das Node-Lease-Feature als Alpha-Feature eingeführt (Feature-Gate `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
|
||||
|
||||
Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird.
|
||||
Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt.
|
||||
Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes).
|
||||
Wenn die Node Lease Funktion aktiviert ist, hat jeder Node ein zugeordnetes `Lease`-Objekt im `kube-node-lease`-Namespace, das vom Node regelmäßig erneuert wird.
|
||||
Sowohl NodeStatus als auch Node Lease werden als Herzschläge vom Node aus behandelt.
|
||||
Node Leases werden häufig erneuert, während NodeStatus nur dann vom Node zu Master gemeldet wird, wenn sich etwas ändert oder genügend Zeit vergangen ist (Standard ist 1 Minute, was länger ist als der Standard-Timeout von 40 Sekunden für unerreichbare Nodes).
|
||||
Da Node Leases viel lastärmer sind als NodeStatus, macht diese Funktion den Node Herzschlag sowohl in Bezug auf Skalierbarkeit als auch auf die Leistung deutlich effizienter.
|
||||
|
||||
In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat).
|
||||
In Kubernetes 1.4 haben wir die Logik der Node-Steuerung aktualisiert, um Fälle besser zu handhaben, in denen eine große Anzahl von Nodes Probleme hat, den Master zu erreichen (z.B. weil der Master Netzwerkprobleme hat).
|
||||
Ab 1.4 betrachtet der Node-Controller den Zustand aller Nodes im Cluster, wenn er eine Entscheidung über die Enterfung eines Pods trifft.
|
||||
|
||||
In den meisten Fällen begrenzt der Node-Controller die Entfernungsrate auf `--node-eviction-rate` (Standard 0,1) pro Sekunde, was bedeutet, dass er die Pods nicht von mehr als einem Node pro 10 Sekunden entfernt.
|
||||
|
||||
Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird.
|
||||
Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse).
|
||||
Das Entfernungsverhalten von Nodes ändert sich, wenn ein Node in einer bestimmten Verfügbarkeitszone ungesund wird.
|
||||
Der Node-Controller überprüft gleichzeitig, wie viel Prozent der Nodes in der Zone ungesund sind (NodeReady-Bedingung ist ConditionUnknown oder ConditionFalse).
|
||||
Wenn der Anteil der ungesunden Nodes mindestens `--unhealthy-zone-threshold` (Standard 0,55) beträgt, wird die Entfernungsrate reduziert:
|
||||
|
||||
Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert.
|
||||
Wenn der Cluster klein ist (d.h. weniger als oder gleich `--large-cluster-size-threshold` Node - Standard 50), werden die Entfernungen gestoppt. Andernfalls wird die Entfernungsrate auf `--secondary-node-eviction-rate` (Standard 0,01) pro Sekunde reduziert.
|
||||
|
||||
Der Grund, warum diese Richtlinien pro Verfügbarkeitszone implementiert werden, liegt darin, dass eine Verfügbarkeitszone vom Master unerreichbar werden könnte, während die anderen verbunden bleiben. Wenn Ihr Cluster nicht mehrere Verfügbarkeitszonen von Cloud-Anbietern umfasst, gibt es nur eine Verfügbarkeitszone (den gesamten Cluster).
|
||||
|
||||
Ein wichtiger Grund für die Verteilung Ihrer Nodes auf Verfügbarkeitszonen ist, dass die Arbeitsbelastung auf gesunde Zonen verlagert werden kann, wenn eine ganze Zone ausfällt.
|
||||
Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.
|
||||
Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster).
|
||||
Wenn also alle Nodes in einer Zone ungesund sind, entfernt Node Controller mit der normalen `--node-eviction-rate` Geschwindigkeit.
|
||||
Der Ausnahmefall ist, wenn alle Zonen völlig ungesund sind (d.h. es gibt keine gesunden Node im Cluster).
|
||||
In diesem Fall geht der Node-Controller davon aus, dass es ein Problem mit der Master-Konnektivität gibt und stoppt alle Entfernungen, bis die Verbindung wiederhergestellt ist.
|
||||
|
||||
Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren.
|
||||
Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen.
|
||||
Ab Kubernetes 1.6 ist der Node-Controller auch für die Entfernung von Pods zuständig, die auf Nodes mit `NoExecute`-Taints laufen, wenn die Pods die Markierungen nicht tolerieren.
|
||||
Zusätzlich ist der NodeController als Alpha-Funktion, die standardmäßig deaktiviert ist, dafür verantwortlich, Taints hinzuzufügen, die Node Probleme, wie `Node unreachable` oder `not ready` entsprechen.
|
||||
Siehe [diese Dokumentation](/docs/concepts/configuration/taint-and-toleration/) für Details über `NoExecute` Taints und die Alpha-Funktion.
|
||||
|
||||
|
||||
@@ -198,7 +198,7 @@ Zur Selbstregistrierung wird das kubelet mit den folgenden Optionen gestartet:
|
||||
- `--node-labels` - Labels, die bei der Registrierung des Nodes im Cluster hinzugefügt werden sollen (Beachten Sie die Richlinien des [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Gibt an, wie oft kubelet den Nodestatus an den Master übermittelt.
|
||||
|
||||
Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und
|
||||
Wenn der [Node authorization mode](/docs/reference/access-authn-authz/node/) und
|
||||
[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) aktiviert sind,
|
||||
dürfen kubelets nur ihre eigene Node-Ressource erstellen / ändern.
|
||||
|
||||
@@ -214,7 +214,7 @@ Zu den Änderungen gehören das Setzen von Labels und das Markieren des Nodes.
|
||||
Labels auf Nodes können in Verbindung mit node selectors auf Pods verwendet werden, um die Planung zu steuern, z.B. um einen Pod so zu beschränken, dass er nur auf einer Teilmenge der Nodes ausgeführt werden darf.
|
||||
|
||||
Das Markieren eines Nodes als nicht geplant, verhindert, dass neue Pods für diesen Node geplant werden. Dies hat jedoch keine Auswirkungen auf vorhandene Pods auf dem Node.
|
||||
Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw.
|
||||
Dies ist nützlich als vorbereitender Schritt vor einem Neustart eines Nodes usw.
|
||||
Um beispielsweise einen Node als nicht geplant zu markieren, führen Sie den folgenden Befehl aus:
|
||||
|
||||
```shell
|
||||
@@ -222,7 +222,7 @@ kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node.
|
||||
Pods, die von einem DaemonSet-Controller erstellt wurden, umgehen den Kubernetes-Scheduler und respektieren nicht das _unschedulable_ Attribut auf einem Node.
|
||||
Dies setzt voraus, dass Daemons auf dem Computer verbleiben, auch wenn während der Vorbereitung eines Neustarts keine Anwendungen mehr vorhanden sind.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -234,7 +234,7 @@ Sofern Sie [Manuelle Nodeverwaltung](#Manuelle-Nodeverwaltung) betreiben, müsse
|
||||
|
||||
Der Kubernetes-Scheduler stellt sicher, dass für alle Pods auf einem Nodes genügend Ressourcen vorhanden sind.
|
||||
Er prüft, dass die Summe der Requests von Containern auf dem Node nicht größer ist als die Kapazität des Nodes.
|
||||
Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen.
|
||||
Er beinhaltet alle Container die vom kubelet gestarted worden, aber keine Container die direkt von der [container runtime](/docs/concepts/overview/components/#node-components) gestartet wurden, noch jegleiche Prozesse die ausserhalb von Containern laufen.
|
||||
|
||||
Wenn Sie Ressourcen explizit für Nicht-Pod-Prozesse reservieren möchten, folgen Sie diesem Lernprogramm um [Ressourcen für Systemdaemons zu reservieren](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
|
||||
In einem Cluster sind die Controller Manager Metriken unter `http://localhost:10252/metrics` auf dem Host verfügbar, auf dem der Controller Manager läuft.
|
||||
|
||||
Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.
|
||||
Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.
|
||||
|
||||
In einer Produktionsumgebung können Sie Prometheus oder einen anderen Metrik Scraper konfigurieren, um diese Metriken regelmäßig zu sammeln und in einer Art Zeitreihen Datenbank verfügbar zu machen.
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes
|
||||
1. Der [kubectl Proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
|
||||
|
||||
- läuft auf dem Desktop eines Benutzers oder in einem Pod
|
||||
- Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
|
||||
- Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
|
||||
- Client zu Proxy verwendet HTTP
|
||||
- Proxy zu API Server verwendet HTTPS
|
||||
- lokalisiert den API Server
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Kubernetes Komponenten
|
||||
content_template: templates/concept
|
||||
weight: 20
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
@@ -50,7 +50,7 @@ Der cloud-controller-manager ist eine Alpha-Funktion, die in Kubernetes Version
|
||||
|
||||
cloud-controller-manager führt nur Cloud-Provider-spezifische Controller-Schleifen aus. Sie müssen diese Controller-Schleifen im Cube-Controller-Manager deaktivieren. Sie können die Controller-Schleifen deaktivieren, indem Sie beim Starten des kube-controller-manager das Flag `--cloud-provider` auf `external` setzen.
|
||||
|
||||
cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln.
|
||||
cloud-controller-manager erlaubt es dem Cloud-Anbieter Code und dem Kubernetes-Code, sich unabhängig voneinander zu entwickeln.
|
||||
In früheren Versionen war der Kerncode von Kubernetes für die Funktionalität von Cloud-Provider-spezifischem Code abhängig.
|
||||
In zukünftigen Versionen sollte der für Cloud-Anbieter spezifische Code vom Cloud-Anbieter selbst verwaltet und mit dem Cloud-Controller-Manager verknüpft werden, während Kubernetes ausgeführt wird.
|
||||
|
||||
@@ -81,7 +81,7 @@ Kubernetes unterstützt mehrere Laufzeiten: [Docker](http://www.docker.com), [co
|
||||
## Addons
|
||||
|
||||
Addons sind Pods und Dienste, die Clusterfunktionen implementieren. Die Pods können verwaltet werden
|
||||
durch Deployments, ReplicationControllers, und so wieter.
|
||||
durch Deployments, ReplicationControllers, und so wieter.
|
||||
Namespace-Addon-Objekte werden im Namespace `kube-system` erstellt.
|
||||
|
||||
Ausgewählte Addons werden unten beschrieben. Eine erweiterte Liste verfügbarer Addons finden Sie unter [Addons](/docs/concepts/cluster-administration/addons/).
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Was ist Kubernetes?
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
---
|
||||
@@ -14,10 +14,10 @@ Diese Seite ist eine Übersicht über Kubernetes.
|
||||
{{% capture body %}}
|
||||
|
||||
Kubernetes ist eine portable, erweiterbare Open-Source-Plattform zur Verwaltung von
|
||||
containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
|
||||
containerisierten Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Automatisierung erleichtert.
|
||||
Es hat einen großes, schnell wachsendes Ökosystem. Kubernetes Dienstleistungen, Support und Tools sind weit verbreitet.
|
||||
|
||||
Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten
|
||||
Google hat das Kubernetes-Projekt 2014 als Open-Source-Projekt zur Verfügung gestellt. Kubernetes baut auf anderthalb Jahrzehnten
|
||||
Erfahrung auf, die Google mit der Ausführung von Produktions-Workloads in großem Maßstab hat, kombiniert mit den besten Ideen und Praktiken der Community.
|
||||
|
||||
## Warum brauche ich Kubernetes und was kann ich damit tun?
|
||||
@@ -29,65 +29,65 @@ Kubernetes hat eine Reihe von Funktionen. Es kann gesehen werden als:
|
||||
- eine portable Cloud-Plattform
|
||||
und vieles mehr.
|
||||
|
||||
Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur
|
||||
im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität
|
||||
Kubernetes bietet eine **containerzentrierte** Managementumgebung. Es koordiniert die Computer-, Netzwerk- und Speicherinfrastruktur
|
||||
im Namen der Benutzer-Workloads. Dies bietet einen Großteil der Einfachheit von Platform as a Service (PaaS) mit der Flexibilität
|
||||
von Infrastructure as a Service (IaaS) und ermöglicht die Portabilität zwischen Infrastrukturanbietern.
|
||||
|
||||
## Wie ist Kubernetes eine Plattform?
|
||||
|
||||
Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien,
|
||||
die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden,
|
||||
um die Entwicklungsgeschwindigkeit zu beschleunigen.
|
||||
Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab.
|
||||
Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools
|
||||
Auch wenn Kubernetes eine Menge Funktionalität bietet, gibt es immer wieder neue Szenarien,
|
||||
die von neuen Funktionen profitieren würden. Anwendungsspezifische Workflows können optimiert werden,
|
||||
um die Entwicklungsgeschwindigkeit zu beschleunigen.
|
||||
Eine zunächst akzeptable Ad-hoc-Orchestrierung erfordert oft eine robuste Automatisierung in großem Maßstab.
|
||||
Aus diesem Grund wurde Kubernetes auch als Plattform für den Aufbau eines Ökosystems von Komponenten und Tools
|
||||
konzipiert, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu erleichtern.
|
||||
|
||||
[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen
|
||||
[Labels](/docs/concepts/overview/working-with-objects/labels/) ermöglichen es den Benutzern, ihre Ressourcen
|
||||
nach Belieben zu organisieren. [Anmerkungen](/docs/concepts/overview/working-with-objects/annotations/) ermöglichen es Benutzern,
|
||||
Ressourcen mit benutzerdefinierten Informationen zu versehen, um ihre Arbeitsabläufe zu vereinfachen und eine einfache Möglichkeit
|
||||
für Managementtools zu bieten, den Status von Kontrollpunkten zu ermitteln.
|
||||
|
||||
|
||||
Darüber hinaus basiert die [Kubernetes-Steuerungsebene](/docs/concepts/overview/components/) auf den gleichen APIs,
|
||||
die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigenen Controller, wie z.B.
|
||||
[Scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), mit
|
||||
ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
|
||||
die Entwicklern und Anwendern zur Verfügung stehen. Benutzer können ihre eigenen Controller, wie z.B.
|
||||
[Scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), mit
|
||||
ihren [eigenen APIs](/docs/concepts/api-extension/custom-resources/) schreiben, die von einem
|
||||
universellen [Kommandozeilen-Tool](/docs/user-guide/kubectl-overview/) angesprochen werden können.
|
||||
|
||||
Dieses [Design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) hat es einer Reihe anderer Systeme ermöglicht, auf Kubernetes aufzubauen.
|
||||
|
||||
## Was Kubernetes nicht ist
|
||||
|
||||
Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
|
||||
sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
|
||||
wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
|
||||
Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
|
||||
Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
|
||||
Kubernetes ist kein traditionelles, allumfassendes PaaS (Plattform als ein Service) System. Da Kubernetes nicht auf Hardware-,
|
||||
sondern auf Containerebene arbeitet, bietet es einige allgemein anwendbare Funktionen, die PaaS-Angeboten gemeinsam sind,
|
||||
wie Bereitstellung, Skalierung, Lastausgleich, Protokollierung und Überwachung.
|
||||
Kubernetes ist jedoch nicht monolithisch, und diese Standardlösungen sind optional und modular etweiterbar.
|
||||
Kubernetes liefert die Bausteine für den Aufbau von Entwicklerplattformen, bewahrt aber die
|
||||
Wahlmöglichkeiten und Flexibilität der Benutzer, wo es wichtig ist.
|
||||
|
||||
Kubernetes:
|
||||
|
||||
* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab,
|
||||
eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless,
|
||||
stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt
|
||||
* Schränkt nicht die Art der unterstützten Anwendungen ein. Kubernetes zielt darauf ab,
|
||||
eine extrem große Vielfalt von Workloads zu unterstützen, einschließlich stateless,
|
||||
stateful und datenverarbeitender Workloads. Wenn eine Anwendung in einem Container ausgeführt
|
||||
werden kann, sollte sie auf Kubernetes hervorragend laufen.
|
||||
* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht.
|
||||
Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch
|
||||
* Verteilt keinen Quellcode und entwickelt Ihre Anwendung nicht.
|
||||
Kontinuierliche Integrations-, Liefer- und Bereitstellungs-Workflows (CI/CD) werden durch
|
||||
Unternehmenskulturen und -präferenzen sowie technische Anforderungen bestimmt.
|
||||
* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse),
|
||||
Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder
|
||||
Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
|
||||
auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
|
||||
* Bietet keine Dienste auf Anwendungsebene, wie Middleware (z.B. Nachrichtenbusse),
|
||||
Datenverarbeitungs-Frameworks (z.B. Spark), Datenbanken (z.B. mysql), Caches oder
|
||||
Cluster-Speichersysteme (z.B. Ceph) als eingebaute Dienste. Solche Komponenten können
|
||||
auf Kubernetes laufen und/oder von Anwendungen, die auf Kubernetes laufen, über
|
||||
portable Mechanismen wie den Open Service Broker angesprochen werden.
|
||||
* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
|
||||
* Bietet keine Konfigurationssprache bzw. kein Konfigurationssystem (z.B.[jsonnet](https://github.com/google/jsonnet)).
|
||||
Es bietet eine deklarative API, die von beliebigen Formen deklarativer Spezifikationen angesprochen werden kann.
|
||||
* Bietet keine umfassenden Systeme zur Maschinenkonfiguration, Wartung, Verwaltung oder Selbstheilung.
|
||||
|
||||
Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung
|
||||
Außerdem ist Kubernetes nicht nur ein *Orchestrierungssystem*. Fakt ist, dass es die Notwendigkeit einer Orchestrierung
|
||||
überflüssig macht. Die technische Definition von *Orchestrierung* ist die Ausführung eines
|
||||
definierten Workflows: zuerst A, dann B, dann C. Im Gegensatz dazu besteht Kubernetes aus einer Reihe von unabhängigen,
|
||||
komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben.
|
||||
Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich.
|
||||
komponierbaren Steuerungsprozessen, die den aktuellen Zustand kontinuierlich in Richtung des bereitgestellten Soll-Zustandes vorantreiben.
|
||||
Es sollte keine Rolle spielen, wie Sie von A nach C kommen. Eine zentrale Steuerung ist ebenfalls nicht erforderlich.
|
||||
Das Ergebnis ist ein System, das einfacher zu bedienen und leistungsfähiger, robuster, widerstandsfähiger und erweiterbar ist.
|
||||
|
||||
## Warum Container?
|
||||
@@ -96,33 +96,33 @@ Sie suchen nach Gründen, warum Sie Container verwenden sollten?
|
||||
|
||||
|
||||
|
||||
Der *Altbekannte* Weg zur Bereitstellung von Anwendungen war die Installation
|
||||
Der *Altbekannte* Weg zur Bereitstellung von Anwendungen war die Installation
|
||||
der Anwendungen auf einem Host mit dem Betriebssystempaketmanager.
|
||||
Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen,
|
||||
Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem
|
||||
Host-Betriebssystem verwoben waren. Man könnte unveränderliche
|
||||
Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts
|
||||
Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen,
|
||||
Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem
|
||||
Host-Betriebssystem verwoben waren. Man könnte unveränderliche
|
||||
Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts
|
||||
und Rollbacks zu erreichen, aber VMs sind schwergewichtig und nicht portierbar.
|
||||
|
||||
Der *Neue Weg* besteht darin, Container auf Betriebssystemebene und nicht auf
|
||||
Hardware-Virtualisierung bereitzustellen. Diese Container sind voneinander
|
||||
und vom Host isoliert: Sie haben ihre eigenen Dateisysteme, sie können die
|
||||
Prozesse des anderen nicht sehen, und ihr Ressourcenverbrauch kann begrenzt
|
||||
werden. Sie sind einfacher zu erstellen als VMs, und da sie von der zugrunde
|
||||
liegenden Infrastruktur und dem Host-Dateisystem entkoppelt sind,
|
||||
Der *Neue Weg* besteht darin, Container auf Betriebssystemebene und nicht auf
|
||||
Hardware-Virtualisierung bereitzustellen. Diese Container sind voneinander
|
||||
und vom Host isoliert: Sie haben ihre eigenen Dateisysteme, sie können die
|
||||
Prozesse des anderen nicht sehen, und ihr Ressourcenverbrauch kann begrenzt
|
||||
werden. Sie sind einfacher zu erstellen als VMs, und da sie von der zugrunde
|
||||
liegenden Infrastruktur und dem Host-Dateisystem entkoppelt sind,
|
||||
sind sie über Clouds und Betriebssystem-Distributionen hinweg portabel.
|
||||
|
||||
Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden.
|
||||
Diese 1:1-Beziehung zwischen Anwendung und Image ermöglicht es, die Vorteile von Containern
|
||||
voll auszuschöpfen. Mit Containern können unveränderliche Container-Images eher zur Build-/Release-Zeit
|
||||
als zur Deployment-Zeit erstellt werden, da jede Anwendung nicht mit dem Rest des Anwendungsstacks komponiert
|
||||
werden muss und auch nicht mit der Produktionsinfrastrukturumgebung verbunden ist. Die Generierung von
|
||||
Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung
|
||||
von der Entwicklung bis zur Produktion zu gewährleisten.
|
||||
Ebenso sind Container wesentlich transparenter als VMs, was die Überwachung und Verwaltung erleichtert.
|
||||
Dies gilt insbesondere dann, wenn die Prozesslebenszyklen der Container von der Infrastruktur verwaltet
|
||||
Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden.
|
||||
Diese 1:1-Beziehung zwischen Anwendung und Image ermöglicht es, die Vorteile von Containern
|
||||
voll auszuschöpfen. Mit Containern können unveränderliche Container-Images eher zur Build-/Release-Zeit
|
||||
als zur Deployment-Zeit erstellt werden, da jede Anwendung nicht mit dem Rest des Anwendungsstacks komponiert
|
||||
werden muss und auch nicht mit der Produktionsinfrastrukturumgebung verbunden ist. Die Generierung von
|
||||
Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung
|
||||
von der Entwicklung bis zur Produktion zu gewährleisten.
|
||||
Ebenso sind Container wesentlich transparenter als VMs, was die Überwachung und Verwaltung erleichtert.
|
||||
Dies gilt insbesondere dann, wenn die Prozesslebenszyklen der Container von der Infrastruktur verwaltet
|
||||
werden und nicht von einem Prozess-Supervisor im Container versteckt werden.
|
||||
Schließlich, mit einer einzigen Anwendung pro Container, wird die Verwaltung
|
||||
Schließlich, mit einer einzigen Anwendung pro Container, wird die Verwaltung
|
||||
der Container gleichbedeutend mit dem Management des Deployments der Anwendung.
|
||||
|
||||
Zusammenfassung der Container-Vorteile:
|
||||
@@ -130,23 +130,23 @@ Zusammenfassung der Container-Vorteile:
|
||||
* **Agile Anwendungserstellung und -bereitstellung**:
|
||||
Einfachere und effizientere Erstellung von Container-Images im Vergleich zur Verwendung von VM-Images.
|
||||
* **Kontinuierliche Entwicklung, Integration und Bereitstellung**:
|
||||
Bietet eine zuverlässige und häufige Erstellung und Bereitstellung von Container-Images
|
||||
Bietet eine zuverlässige und häufige Erstellung und Bereitstellung von Container-Images
|
||||
mit schnellen und einfachen Rollbacks (aufgrund der Unveränderlichkeit des Images).
|
||||
* **Dev und Ops Trennung der Bedenken**:
|
||||
Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt
|
||||
Erstellen Sie Anwendungscontainer-Images nicht zum Deployment-, sondern zum Build-Releasezeitpunkt
|
||||
und entkoppeln Sie so Anwendungen von der Infrastruktur.
|
||||
* **Überwachbarkeit**
|
||||
Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt,
|
||||
Nicht nur Informationen und Metriken auf Betriebssystemebene werden angezeigt,
|
||||
sondern auch der Zustand der Anwendung und andere Signale.
|
||||
* **Umgebungskontinuität in Entwicklung, Test und Produktion**:
|
||||
Läuft auf einem Laptop genauso wie in der Cloud.
|
||||
* **Cloud- und OS-Distribution portabilität**:
|
||||
Läuft auf Ubuntu, RHEL, CoreOS, On-Prem, Google Kubernetes Engine und überall sonst.
|
||||
* **Anwendungsorientiertes Management**:
|
||||
Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware
|
||||
Erhöht den Abstraktionsgrad vom Ausführen eines Betriebssystems auf virtueller Hardware
|
||||
bis zum Ausführen einer Anwendung auf einem Betriebssystem unter Verwendung logischer Ressourcen.
|
||||
* **Locker gekoppelte, verteilte, elastische, freie [micro-services](https://martinfowler.com/articles/microservices.html)**:
|
||||
Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt
|
||||
Anwendungen werden in kleinere, unabhängige Teile zerlegt und können dynamisch bereitgestellt
|
||||
und verwaltet werden -- nicht ein monolithischer Stack, der auf einer großen Single-Purpose-Maschine läuft.
|
||||
* **Ressourcenisolierung**:
|
||||
Vorhersehbare Anwendungsleistung.
|
||||
|
||||
Reference in New Issue
Block a user