Skip to content

Commit eceba78

Browse files
mkorbiwahyuoi
mkorbi
authored and
wahyuoi
committed
German translation for proxies and controller metrics (kubernetes#15746)
* i18n cloud controller * add controller metrics * 2nd check on controller metrics * add proxies * check proxies * add controller metrics * 2nd check on controller metrics * add proxies * check proxies * Revert "Merge branch 'i18n-003' of github.com:mkorbi/website into i18n-003" This reverts commit 76bf403.
1 parent 0db9da9 commit eceba78

File tree

2 files changed

+105
-0
lines changed

2 files changed

+105
-0
lines changed

‎content/de/docs/concepts/cluster-administration/controller-metrics.md

+41
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
---
2+
title: Controller Manager Metriken
3+
content_template: templates/concept
4+
weight: 100
5+
---
6+
7+
{{% capture overview %}}
8+
Controller Manager Metriken liefern wichtige Erkenntnisse über die Leistung und den Zustand von den Controller Managern.
9+
10+
{{% /capture %}}
11+
12+
{{% capture body %}}
13+
## Was sind Controller Manager Metriken
14+
15+
Die Kennzahlen des Controller Managers liefert wichtige Erkenntnisse über die Leistung und den Zustand des Controller Managers.
16+
Diese Metriken beinhalten gängige Go Language Laufzeitmetriken wie go_routine count und controller-spezifische Metriken wie z.B.
17+
etcd Request Latenzen oder Cloud Provider (AWS, GCE, OpenStack) API Latenzen, die verwendet werden können um den Zustand eines Clusters zu messen.
18+
19+
Ab Kubernetes 1.7 stehen detaillierte Cloud Provider Metriken für den Speicherbetrieb für GCE, AWS, Vsphere und OpenStack zur Verfügung.
20+
Diese Metriken können verwendet werden, um den Zustand persistenter Datenträgeroperationen zu überwachen.
21+
22+
Für GCE werden diese Metriken beispielsweise wie folgt aufgerufen:
23+
24+
```
25+
cloudprovider_gce_api_request_duration_seconds { request = "instance_list"}
26+
cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"}
27+
cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"}
28+
cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"}
29+
cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
30+
cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
31+
```
32+
33+
## Konfiguration
34+
35+
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.
36+
37+
Die Metriken werden im [Prometheus Format](https://prometheus.io/docs/instrumenting/exposition_formats/) ausgegeben.
38+
39+
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.
40+
41+
{{% /capture %}}

‎content/de/docs/concepts/cluster-administration/proxies.md

+64
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,64 @@
1+
---
2+
title: Proxies in Kubernetes
3+
content_template: templates/concept
4+
weight: 90
5+
---
6+
7+
{{% capture overview %}}
8+
Auf dieser Seite werden die im Kubernetes verwendeten Proxies erläutert.
9+
{{% /capture %}}
10+
11+
{{% capture body %}}
12+
13+
## Proxies
14+
15+
Es gibt mehrere verschiedene Proxies, die die bei der Verwendung von Kubernetes begegnen können:
16+
17+
1. Der [kubectl Proxy](/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api):
18+
19+
- läuft auf dem Desktop eines Benutzers oder in einem Pod
20+
- Proxy von einer lokalen Host-Adresse zum Kubernetes API Server
21+
- Client zu Proxy verwendet HTTP
22+
- Proxy zu API Server verwendet HTTPS
23+
- lokalisiert den API Server
24+
- fügt Authentifizierungs-Header hinzu
25+
26+
1. Der [API Server Proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
27+
28+
- ist eine Bastion, die in den API Server eingebaut ist
29+
- verbindet einen Benutzer außerhalb des Clusters mit Cluster IPs, die sonst möglicherweise nicht erreichbar wären
30+
- läuft im API Server Prozess
31+
- Client zu Proxy verwendet HTTPS (oder http, wenn API Server so konfiguriert ist)
32+
- Proxy zum Ziel kann HTTP oder HTTPS verwenden, der Proxy wählt dies unter Verwendung der verfügbaren Informationen aus
33+
- kann verwendet werden, um einen Knoten, Pod oder Service zu erreichen
34+
- führt einen Lastausgleich durch um einen Service zu erreichen, wenn dieser verwendet wird
35+
36+
1. Der [kube Proxy](/docs/concepts/services-networking/service/#ips-and-vips):
37+
38+
- läuft auf jedem Knoten
39+
- Proxy unterstüzt UDP, TCP und SCTP
40+
- versteht kein HTTP
41+
- stellt Lastausgleich zur Verfügung
42+
- wird nur zum erreichen von Services verwendet
43+
44+
1. Ein Proxy/Load-balancer vor dem API Server:
45+
46+
- Existenz und Implementierung variieren von Cluster zu Cluster (z.B. nginx)
47+
- sitzt zwischen allen Clients und einem oder mehreren API Servern
48+
- fungiert als Load Balancer, wenn es mehrere API Server gibt
49+
50+
1. Cloud Load Balancer für externe Services:
51+
52+
- wird von einigen Cloud Anbietern angeboten (z.B. AWS ELB, Google Cloud Load Balancer)
53+
- werden automatisch erstellt, wenn der Kubernetes Service den Typ `LoadBalancer` hat
54+
- unterstützt normalerweiße nur UDP/TCP
55+
- Die SCTP-Unterstützung hängt von der Load Balancer Implementierung des Cloud Providers ab
56+
- die Implementierung variiert je nach Cloud Anbieter
57+
58+
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.
59+
60+
## Anforderung an Umleitungen
61+
62+
Proxies haben die Möglichkeit der Umleitung (redirect) ersetzt. Umleitungen sind veraltet.
63+
64+
{{% /capture %}}

0 commit comments

Comments
 (0)