From d51eafbff569e0b6c873cbaa2ac0b04e00674395 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Max=20K=C3=B6rb=C3=A4cher?= Date: Wed, 7 Aug 2019 18:16:17 +0200 Subject: [PATCH 1/5] i18n cloud controller --- .../concepts/architecture/cloud-controller.md | 238 ++++++++++++++++++ 1 file changed, 238 insertions(+) create mode 100644 content/de/docs/concepts/architecture/cloud-controller.md diff --git a/content/de/docs/concepts/architecture/cloud-controller.md b/content/de/docs/concepts/architecture/cloud-controller.md new file mode 100644 index 00000000000..6604110e1cf --- /dev/null +++ b/content/de/docs/concepts/architecture/cloud-controller.md @@ -0,0 +1,238 @@ +--- +title: Concepts Underlying the Cloud Controller Manager +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} +Das Konzept des Cloud Controller Managers (CCM) (nicht zu verwechseln mit der Binärdatei) wurde ursprünglich entwickelt, um Cloud-spezifischen Anbieter-Code und den Kubernetes Kern unabhängig voneinander entwickeln zu können. Der Cloud Controller Manager läuft zusammen mit anderen Master-Komponenten wie dem Kubernetes Controller Manager, dem API-Server und dem Scheduler auf dem Host. Es kann auch als Kubernetes-Addon gestartet werden, in diesem Fall läuft er auf Kubernetes. + +Das Design des Cloud Controller Managers basiert auf einem Plugin Mechanismus, der es neuen Cloud Anbietern ermöglicht, sich mit Kubernetes einfach über Plugins zu integrieren. Es gibt Pläne für die Einbindung neuer Cloud Anbieter auf Kubernetes und für die Migration von Cloud Anbietern vom alten Modell auf das neue CCM-Modell. + +Dieses Dokument beschreibt die Konzepte hinter dem Cloud Controller Manager und gibt Details zu den damit verbundenen Funktionen. + +Die Architektur eines Kubernetes Clusters ohne den Cloud Controller Manager sieht wie folgt aus: + +![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) + +{{% /capture %}} + + +{{% capture body %}} + +## Design + +Im vorhergehenden Diagramm sind Kubernetes und der Cloud-Provider über mehrere verschiedene Komponenten integriert: + +* Kubelet +* Kubernetes Controller Manager +* Kubernetes API Server + +CCM konsolidiert die gesamte Abhängigkeit der Cloud Logik von den drei vorhergehenden Komponenten zu einem einzigen Integrationspunkt mit der Cloud. So sieht die neue Architektur mit dem CCM aus: + +![CCM Kube Arch](/images/docs/post-ccm-arch.png) + +## Components of the CCM + +Der CCM löst einen Teil der Funktionalität des Kubernetes Controller Managers (KCM) ab und führt ihn als separaten Prozess aus. Konkret trennt es die Cloud abhängigen Controller im KCM. Das KCM verfügt über die folgenden Cloud abhängigen Steuerungsschleifen: + + * Node Controller + * Volume Controller + * Route Controller + * Service Controller + +In der Version 1.9 führt der CCM die folgenden Controller aus der vorhergehenden Liste aus: + +* Node Controller +* Route Controller +* Service Controller + +{{< note >}} +Der Volume Controller wurde bewusst nicht als Teil des CCM gewählt. Aufgrund der Komplexität und der bestehenden Bemühungen, herstellerspezifische Volumelogik zu abstrahieren, wurde entschieden, dass der Volumecontroller nicht zum CCM verschoben wird. +{{< /note >}} + +Der ursprüngliche Plan, Volumes mit CCM zu unterstützen, war die Verwendung von Flex-Volumes zur Unterstützung von austauschbaren Volumes. Allerdings ist eine konkurrierende Initiative namens CSI geplant, um Flex zu ersetzen. + +In Anbetracht dieser Dynamik haben wir uns entschieden, eine Zwischenstopp durchzuführen um die Unterschiede zu beobachten , bis das CSI bereit ist. + +## Funktionen des CCM + +Das CCM erbt seine Funktionen von Komponenten des Kubernetes, die von einem Cloud Provider abhängig sind. Dieser Abschnitt ist auf der Grundlage dieser Komponenten strukturiert. + +### 1. Kubernetes Controller Manager + +Die meisten Funktionen des CCM stammen aus dem KCM. Wie im vorherigen Abschnitt erwähnt, führt das CCM die folgenden Steuerschleifen durch: + +* Node Controller +* Route Controller +* Service Controller + +#### Node Controller + +Der Node Controller ist für die Initialisierung eines Knotens verantwortlich, indem er Informationen über die im Cluster laufenden Knoten vom CloudmProvider erhält. Der Node Controller führt die folgenden Funktionen aus: + +1. Initialisierung eines Knoten mit Cloud-spezifischen Zonen-/Regionen Labels. +2. Initialisieren von Knoten mit Cloud-spezifischen Instanzdetails, z.B. Typ und Größe. +3. Ermitteln der Netzwerkadressen und des Hostnamen des Knotens. +4. Falls ein Knoten nicht mehr reagiert, überprüft der Controller die Cloud, um festzustellen, ob der Knoten aus der Cloud gelöscht wurde. +Wenn der Knoten aus der Cloud gelöscht wurde, löscht der Controller das Kubernetes Node Objekt. + +#### Route Controller + +Der Route Controller ist dafür verantwortlich, Routen in der Cloud so zu konfigurieren, dass Container auf verschiedenen Knoten im Kubernetes Cluster miteinander kommunizieren können. Der Route Controller ist nur auf einem Google Compute Engine Cluster anwendbar. + +#### Service Controller + +Der Service Controller ist verantwortlich für das Abhören von Ereignissen zum Erstellen, Aktualisieren und Löschen von Diensten. Basierend auf dem aktuellen Stand der Services in Kubernetes konfiguriert es Cloud Load Balancer (wie ELB, Google LB oder Oracle Cloud Infrastructure LB), um den Zustand der Services in Kubernetes abzubilden. Darüber hinaus wird sichergestellt, dass die Service Backends für Cloud Loadbalancer auf dem neuesten Stand sind. + +### 2. Kubelet + +Der Node Controller enthält die Cloud-abhängige Funktionalität des Kubelets. Vor der Einführung des CCM war das Kubelet für die Initialisierung eines Knotens mit cloudspezifischen Details wie IP-Adressen, Regions-/Zonenbezeichnungen und Instanztypinformationen verantwortlich. Mit der Einführung des CCM wurde diese Initialisierungsoperation aus dem Kubelet in das CCM verschoben. + +In diesem neuen Modell initialisiert das Kubelet einen Knoten ohne cloudspezifische Informationen. Es fügt jedoch dem neu angelegten Knoten einen Taint hinzu, der den Knoten nicht planbar macht, bis der CCM den Knoten mit cloudspezifischen Informationen initialisiert. Dann wird der Taint entfernt. + +## Plugin Mechanismus + +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. + +Weitere Informationen zur Entwicklung von Plugins findest du im Bereich [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). + +## Autorisierung + +Dieser Abschnitt beschreibt den Zugriff, den der CCM für die Ausführung seiner Operationen auf verschiedene API Objekte benötigt. + +### Node Controller + +Der Node Controller funktioniert nur mit Node Objekten. Es benötigt vollen Zugang zu get, list, create, update, patch, watch, und delete Node Objekten. + +v1/Node: + +- Get +- List +- Create +- Update +- Patch +- Watch +- Delete + +### Route Controller + +Der Route Controller horcht auf die Erstellung von Node Objekten und konfiguriert die Routen entsprechend. Es erfordert get Zugriff auf die Node Objekte. + +v1/Node: + +- Get + +### Service Controller + +Der Service Controller hört auf die Service Objekt Events create, update und delete und konfiguriert dann die Endpunkte für diese Services entsprechend. + +Um auf Services zuzugreifen, benötigt man list und watch Berechtigung. Um die Services zu aktualisieren, sind patch und update Zugriffsrechte erforderlich. + +Um die Endpunkte für die Dienste einzurichten, benötigt der Controller Zugriff auf create, list, get, watch und update. + +v1/Service: + +- List +- Get +- Watch +- Patch +- Update + +### Sonstiges + +Die Implementierung des Kerns des CCM erfordert den Zugriff auf die Erstellung von Ereignissen und zur Gewährleistung eines sicheren Betriebs den Zugriff auf die Erstellung von ServiceAccounts. + +v1/Event: + +- Create +- Patch +- Update + +v1/ServiceAccount: + +- Create + +Die RBAC ClusterRole für CCM sieht wie folgt aus: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cloud-controller-manager +rules: +- apiGroups: + - "" + resources: + - events + verbs: + - create + - patch + - update +- apiGroups: + - "" + resources: + - nodes + verbs: + - '*' +- apiGroups: + - "" + resources: + - nodes/status + verbs: + - patch +- apiGroups: + - "" + resources: + - services + verbs: + - list + - patch + - update + - watch +- apiGroups: + - "" + resources: + - serviceaccounts + verbs: + - create +- apiGroups: + - "" + resources: + - persistentvolumes + verbs: + - get + - list + - update + - watch +- apiGroups: + - "" + resources: + - endpoints + verbs: + - create + - get + - list + - watch + - update +``` + +## Anbieter Implementierung + +Die folgenden Cloud Anbieter haben CCMs implementiert: + +* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager) +* [Oracle](https://github.com/oracle/oci-cloud-controller-manager) +* [Azure](https://github.com/kubernetes/cloud-provider-azure) +* [GCP](https://github.com/kubernetes/cloud-provider-gcp) +* [AWS](https://github.com/kubernetes/cloud-provider-aws) +* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [Linode](https://github.com/linode/linode-cloud-controller-manager) + +## Cluster Administration + +Eine vollständige Anleitung zur Konfiguration und zum Betrieb des CCM finden Sie [hier](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). + +{{% /capture %}} \ No newline at end of file From 23eebda78cf1daa076768883ed0fedc1f71ecbde Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Max=20K=C3=B6rb=C3=A4cher?= Date: Thu, 8 Aug 2019 13:39:49 +0200 Subject: [PATCH 2/5] add controller metrics --- .../controller-metrics.md | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 content/de/docs/concepts/cluster-administration/controller-metrics.md diff --git a/content/de/docs/concepts/cluster-administration/controller-metrics.md b/content/de/docs/concepts/cluster-administration/controller-metrics.md new file mode 100644 index 00000000000..745abdbcd0c --- /dev/null +++ b/content/de/docs/concepts/cluster-administration/controller-metrics.md @@ -0,0 +1,41 @@ +--- +title: Controller Manager Metriken +content_template: templates/concept +weight: 100 +--- + +{{% capture overview %}} +Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und den Zustand von den Controller Managern. + +{{% /capture %}} + +{{% capture body %}} +## Was sind Controller Manager Metriken + +Die Kennzahlen des Controllermanagers liefern wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers. +Diese Metriken beinhalten gängige Go Language Laufzeitmetriken wie go_routine count und controller-spezifische Metriken wie z.B. +etcd Request Latenzen oder Cloud Provider (AWS, GCE, OpenStack) API Latenzen, die verwendet werden können um den Zustand eines Clusters zu messen. + +Ab Kubernetes 1.7 stehen detaillierte Cloud Provider Metriken für den Speicherbetrieb für GCE, AWS, Vsphere und OpenStack zur Verfügung. +Diese Metriken können verwendet werden, um den Zustand persistenter Datenträgeroperationen zu überwachen. + +Für GCE werden diese Metriken beispielsweise wie folgt aufgerufen: + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + +## Konfiguration + +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. + +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. + +{{% /capture %}} \ No newline at end of file From c3c112a726da3d21018441efd37d9cc6666205a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Max=20K=C3=B6rb=C3=A4cher?= Date: Thu, 8 Aug 2019 14:04:10 +0200 Subject: [PATCH 3/5] 2nd check on controller metrics --- .../docs/concepts/cluster-administration/controller-metrics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/de/docs/concepts/cluster-administration/controller-metrics.md b/content/de/docs/concepts/cluster-administration/controller-metrics.md index 745abdbcd0c..2444c5d37aa 100644 --- a/content/de/docs/concepts/cluster-administration/controller-metrics.md +++ b/content/de/docs/concepts/cluster-administration/controller-metrics.md @@ -12,7 +12,7 @@ Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und {{% capture body %}} ## Was sind Controller Manager Metriken -Die Kennzahlen des Controllermanagers liefern wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers. +Die Kennzahlen des Controller Managers liefert wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers. Diese Metriken beinhalten gängige Go Language Laufzeitmetriken wie go_routine count und controller-spezifische Metriken wie z.B. etcd Request Latenzen oder Cloud Provider (AWS, GCE, OpenStack) API Latenzen, die verwendet werden können um den Zustand eines Clusters zu messen. From 29b7f71fda3f7773ef31c5481d03997dce706127 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Max=20K=C3=B6rb=C3=A4cher?= Date: Thu, 8 Aug 2019 14:24:55 +0200 Subject: [PATCH 4/5] add proxies --- .../cluster-administration/proxies.md | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 content/de/docs/concepts/cluster-administration/proxies.md diff --git a/content/de/docs/concepts/cluster-administration/proxies.md b/content/de/docs/concepts/cluster-administration/proxies.md new file mode 100644 index 00000000000..b9bb1a42c8d --- /dev/null +++ b/content/de/docs/concepts/cluster-administration/proxies.md @@ -0,0 +1,64 @@ +--- +title: Proxies in Kubernetes +content_template: templates/concept +weight: 90 +--- + +{{% capture overview %}} +Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert. +{{% /capture %}} + +{{% capture body %}} + +## Proxies + +Es gibt mehrere verschiedene Proxies, die bei der Verwendung von Kubernetes begegnen können: + +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 + - Proxies von einer lokalen Host-Adresse zum Kubernetes Apiserver + - Client zu Proxy verwendet HTTP + - Proxy zu apiserver verwendet HTTPS + - lokalisiert den apiserver + - fügt Authentifizierungs-Header hinzu + +1. Der [apiserver Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): + + - ist eine Bastion, die in den Apiserver eingebaut ist + - verbindet einen Benutzer außerhalb des Clusters mit Cluster IPs, die sonst möglicherweise nicht erreichbar wären + - läuft im apiserver Prozess + - Client zu Proxy verwendet HTTPS (oder http, wenn apiserver so konfiguriert ist) + - Proxy zum Ziel kann HTTP oder HTTPS verwenden, der Proxy wählt dies unter Verwendung der verfügbaren Informationen aus + - kann verwendet werden, um einen Knoten, Pod oder Service zu erreichen + - führt einen Lastausgleich durch um einen Service zu erreichen, wenn er verwendet wird + +1. Der [kube Proxy](/docs/concepts/services-networking/service/#ips-and-vips): + + - läuft auf jedem Knoten + - Proxies UDP, TCP und SCTP + - versteht kein HTTP + - stellt Lastausgleich zur Verfügung + - wird nur zum erreichen von Services verwendet + +1. Ein Proxy/Load-balancer vor dem apiserver(s): + + - Existenz und Implementierung variieren von Cluster zu Cluster (z.B. nginx) + - sitzt zwischen allen Clients und einem oder mehreren apiservern + - fungiert als Load Balancer, wenn es mehrere apiserver gibt + +1. Cloud Load Balancer für externe Services: + + - werden von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer) + - werden automatisch erstellt, wenn der Kubernetes Service den Typ `LoadBalancer` hat + - unterstützt normalerweiße nur UDP/TCP + - Die SCTP-Unterstützung hängt von der Load Balancer Implementierung des Cloud Providers ab + - die Implementierung variiert je nach Cloud Anbieter + +Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten beiden Typen kümmern. Der Cluster Administrator stellt in der Regel sicher, dass die letztgenannten Typen korrekt eingerichtet sind. + +## Anforderung von Umleitungen + +Proxies haben die Möglichkeit der Umleitung ersetzt. Umleitungen sind veraltet. + +{{% /capture %}} \ No newline at end of file From c17aa5f6f86b3009a390061fc29c1ff033459d35 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Max=20K=C3=B6rb=C3=A4cher?= Date: Thu, 8 Aug 2019 16:51:11 +0200 Subject: [PATCH 5/5] check proxies --- .../cluster-administration/proxies.md | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/content/de/docs/concepts/cluster-administration/proxies.md b/content/de/docs/concepts/cluster-administration/proxies.md index b9bb1a42c8d..7422d551357 100644 --- a/content/de/docs/concepts/cluster-administration/proxies.md +++ b/content/de/docs/concepts/cluster-administration/proxies.md @@ -12,53 +12,53 @@ Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert. ## Proxies -Es gibt mehrere verschiedene Proxies, die bei der Verwendung von Kubernetes begegnen können: +Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes begegnen können: 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 - - Proxies von einer lokalen Host-Adresse zum Kubernetes Apiserver + - Proxy von einer lokalen Host-Adresse zum Kubernetes API Server - Client zu Proxy verwendet HTTP - - Proxy zu apiserver verwendet HTTPS - - lokalisiert den apiserver + - Proxy zu API Server verwendet HTTPS + - lokalisiert den API Server - fügt Authentifizierungs-Header hinzu -1. Der [apiserver Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): +1. Der [API Server Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): - - ist eine Bastion, die in den Apiserver eingebaut ist + - ist eine Bastion, die in den API Server eingebaut ist - verbindet einen Benutzer außerhalb des Clusters mit Cluster IPs, die sonst möglicherweise nicht erreichbar wären - - läuft im apiserver Prozess - - Client zu Proxy verwendet HTTPS (oder http, wenn apiserver so konfiguriert ist) + - läuft im API Server Prozess + - Client zu Proxy verwendet HTTPS (oder http, wenn API Server so konfiguriert ist) - Proxy zum Ziel kann HTTP oder HTTPS verwenden, der Proxy wählt dies unter Verwendung der verfügbaren Informationen aus - kann verwendet werden, um einen Knoten, Pod oder Service zu erreichen - - führt einen Lastausgleich durch um einen Service zu erreichen, wenn er verwendet wird + - führt einen Lastausgleich durch um einen Service zu erreichen, wenn dieser verwendet wird 1. Der [kube Proxy](/docs/concepts/services-networking/service/#ips-and-vips): - läuft auf jedem Knoten - - Proxies UDP, TCP und SCTP + - Proxy unterstüzt UDP, TCP und SCTP - versteht kein HTTP - stellt Lastausgleich zur Verfügung - wird nur zum erreichen von Services verwendet -1. Ein Proxy/Load-balancer vor dem apiserver(s): +1. Ein Proxy/Load-balancer vor dem API Server: - Existenz und Implementierung variieren von Cluster zu Cluster (z.B. nginx) - - sitzt zwischen allen Clients und einem oder mehreren apiservern - - fungiert als Load Balancer, wenn es mehrere apiserver gibt + - sitzt zwischen allen Clients und einem oder mehreren API Servern + - fungiert als Load Balancer, wenn es mehrere API Server gibt 1. Cloud Load Balancer für externe Services: - - werden von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer) + - wird von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer) - werden automatisch erstellt, wenn der Kubernetes Service den Typ `LoadBalancer` hat - unterstützt normalerweiße nur UDP/TCP - Die SCTP-Unterstützung hängt von der Load Balancer Implementierung des Cloud Providers ab - die Implementierung variiert je nach Cloud Anbieter -Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten beiden Typen kümmern. Der Cluster Administrator stellt in der Regel sicher, dass die letztgenannten Typen korrekt eingerichtet sind. +Kubernetes Benutzer müssen sich in der Regel um nichts anderes als die ersten beiden Typen kümmern. Der Cluster Administrator stellt in der Regel sicher, dass die letztgenannten Typen korrekt eingerichtet sind. -## Anforderung von Umleitungen +## Anforderung an Umleitungen -Proxies haben die Möglichkeit der Umleitung ersetzt. Umleitungen sind veraltet. +Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet. {{% /capture %}} \ No newline at end of file