From 5eadf77b1457b2179b07737620c672471f67f5bf Mon Sep 17 00:00:00 2001 From: Arnaud Meukam Date: Tue, 6 Oct 2020 00:42:07 +0200 Subject: [PATCH 0001/1733] Add Container image build automation As suggested by BenTheElder, we need to add a cloudbuild.yaml spec that will be used by the prow job to automate the container build and push the tags. Signed-off-by: Arnaud Meukam --- Makefile | 3 ++- cloudbuild.yaml | 24 ++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 cloudbuild.yaml diff --git a/Makefile b/Makefile index 56ec8410f4..944b6af3a9 100644 --- a/Makefile +++ b/Makefile @@ -6,8 +6,9 @@ NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda # but this can be overridden when calling make, e.g. # CONTAINER_ENGINE=podman make container-image CONTAINER_ENGINE ?= docker +IMAGE_REGISTRY ?= gcr.io/k8s-staging-sig-docs IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile | cut -c 1-12) -CONTAINER_IMAGE = kubernetes-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION) +CONTAINER_IMAGE = $(IMAGE_REGISTRY)/k8s-website-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION) CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src CCRED=\033[0;31m diff --git a/cloudbuild.yaml b/cloudbuild.yaml new file mode 100644 index 0000000000..6d2ac0a024 --- /dev/null +++ b/cloudbuild.yaml @@ -0,0 +1,24 @@ +# See https://cloud.google.com/cloud-build/docs/build-config + +# this must be specified in seconds. If omitted, defaults to 600s (10 mins) +timeout: 1200s +# this prevents errors if you don't use both _GIT_TAG and _PULL_BASE_REF, +# or any new substitutions added in the future. +options: + substitution_option: ALLOW_LOOSE +steps: + - name: "gcr.io/k8s-testimages/gcb-docker-gcloud:v20190906-745fed4" + entrypoint: make + env: + - DOCKER_CLI_EXPERIMENTAL=enabled + - TAG=$_GIT_TAG + - BASE_REF=$_PULL_BASE_REF + args: + - container-image +substitutions: + # _GIT_TAG will be filled with a git-based tag for the image, of the form vYYYYMMDD-hash, and + # can be used as a substitution + _GIT_TAG: "12345" + # _PULL_BASE_REF will contain the ref that was pushed to to trigger this build - + # a branch like 'master' or 'release-0.2', or a tag like 'v0.2'. + _PULL_BASE_REF: "master" From 968512ada1eae813ab20ffdce76b1e5508c198b1 Mon Sep 17 00:00:00 2001 From: "Anna Jung (VMware)" Date: Wed, 9 Dec 2020 10:06:23 -0600 Subject: [PATCH 0002/1733] Tracking commit for v1.21 docs From e4ac283321c9eedbd24dfa42a81f18eab717a0b8 Mon Sep 17 00:00:00 2001 From: carlory Date: Mon, 4 Jan 2021 15:39:01 +0800 Subject: [PATCH 0003/1733] deprecate kubeadm alpha kubeconfig in 1.21 --- .../reference/setup-tools/kubeadm/_index.md | 2 + .../generated/kubeadm_alpha_kubelet.md | 48 --------- .../generated/kubeadm_alpha_kubelet_config.md | 48 --------- ...adm_alpha_kubelet_config_enable-dynamic.md | 87 ---------------- .../generated/kubeadm_alpha_selfhosting.md | 48 --------- .../kubeadm_alpha_selfhosting_pivot.md | 99 ------------------- ...ha_kubeconfig.md => kubeadm_kubeconfig.md} | 2 - ...fig_user.md => kubeadm_kubeconfig_user.md} | 5 +- .../setup-tools/kubeadm/kubeadm-alpha.md | 29 +----- .../setup-tools/kubeadm/kubeadm-kubeconfig.md | 21 ++++ 10 files changed, 26 insertions(+), 363 deletions(-) delete mode 100644 content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md delete mode 100644 content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md delete mode 100644 content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md delete mode 100644 content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md delete mode 100644 content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md rename content/en/docs/reference/setup-tools/kubeadm/generated/{kubeadm_alpha_kubeconfig.md => kubeadm_kubeconfig.md} (93%) rename content/en/docs/reference/setup-tools/kubeadm/generated/{kubeadm_alpha_kubeconfig_user.md => kubeadm_kubeconfig_user.md} (92%) create mode 100644 content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md diff --git a/content/en/docs/reference/setup-tools/kubeadm/_index.md b/content/en/docs/reference/setup-tools/kubeadm/_index.md index d747c05124..ad84378d1d 100755 --- a/content/en/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/en/docs/reference/setup-tools/kubeadm/_index.md @@ -26,5 +26,7 @@ To install kubeadm, see the [installation guide](/docs/setup/production-environm * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` +* [kubeadm certs](/docs/reference/setup-tools/kubeadm/kubeadm-certs) to manage Kubernetes certificates +* [kubeadm kubeconfig](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig) to manage kubeconfig files * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md deleted file mode 100644 index 055c8ecac5..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -This command is not meant to be run on its own. See list of available subcommands. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for kubelet
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md deleted file mode 100644 index 563d9fe227..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -This command is not meant to be run on its own. See list of available subcommands. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for config
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md deleted file mode 100644 index 278def1dd3..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md +++ /dev/null @@ -1,87 +0,0 @@ - -### Synopsis - - -Enable or update dynamic kubelet configuration for a Node, against the kubelet-config-1.X ConfigMap in the cluster, where X is the minor version of the desired kubelet version. - -WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it may have surprising side-effects at this stage. - -Alpha Disclaimer: this command is currently alpha. - -``` -kubeadm alpha kubelet config enable-dynamic [flags] -``` - -### Examples - -``` - # Enable dynamic kubelet configuration for a Node. - kubeadm alpha phase kubelet enable-dynamic-config --node-name node-1 --kubelet-version 1.18.0 - - WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it - may have surprising side-effects at this stage. -``` - -### Options - - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-h, --help
help for enable-dynamic
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
--kubelet-version string
The desired version for the kubelet
--node-name string
Name of the node that should enable the dynamic kubelet configuration
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md deleted file mode 100644 index 77646b064b..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -This command is not meant to be run on its own. See list of available subcommands. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for selfhosting
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md deleted file mode 100644 index 554b8fe4c6..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md +++ /dev/null @@ -1,99 +0,0 @@ - -### Synopsis - - -Convert static Pod files for control plane components into self-hosted DaemonSets configured via the Kubernetes API. - -See the documentation for self-hosting limitations. - -Alpha Disclaimer: this command is currently alpha. - -``` -kubeadm alpha selfhosting pivot [flags] -``` - -### Examples - -``` - # Convert a static Pod-hosted control plane into a self-hosted one. - - kubeadm alpha phase self-hosting convert-from-staticpods -``` - -### Options - - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--cert-dir string     Default: "/etc/kubernetes/pki"
The path where certificates are stored
--config string
Path to a kubeadm configuration file.
-f, --force
Pivot the cluster without prompting for confirmation
-h, --help
help for pivot
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
-s, --store-certs-in-secrets
Enable storing certs in secrets
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md similarity index 93% rename from content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md rename to content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md index 67f30bc3f8..67ee58fdd7 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md @@ -4,8 +4,6 @@ Kubeconfig file utilities. -Alpha Disclaimer: this command is currently alpha. - ### Options diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig_user.md similarity index 92% rename from content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md rename to content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig_user.md index bdb246232f..8ff987503c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig_user.md @@ -4,17 +4,16 @@ Output a kubeconfig file for an additional user. -Alpha Disclaimer: this command is currently alpha. ``` -kubeadm alpha kubeconfig user [flags] +kubeadm kubeconfig user [flags] ``` ### Examples ``` # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar - kubeadm alpha kubeconfig user --client-name=foo --config=bar + kubeadm kubeconfig user --client-name=foo --config=bar ``` ### Options diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md index eaef0f5140..dd946c9737 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md @@ -9,34 +9,7 @@ weight: 90 from the community. Please try it out and give us feedback! {{< /caution >}} -## kubeadm alpha kubeconfig user {#cmd-phase-kubeconfig} - -The `user` subcommand can be used for the creation of kubeconfig files for additional users. - -{{< tabs name="tab-kubeconfig" >}} -{{< tab name="kubeconfig" include="generated/kubeadm_alpha_kubeconfig.md" />}} -{{< tab name="user" include="generated/kubeadm_alpha_kubeconfig_user.md" />}} -{{< /tabs >}} - -## kubeadm alpha kubelet config {#cmd-phase-kubelet} - -Use the following command to enable the DynamicKubeletConfiguration feature. - -{{< tabs name="tab-kubelet" >}} -{{< tab name="kubelet" include="generated/kubeadm_alpha_kubelet.md" />}} -{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}} -{{< /tabs >}} - -## kubeadm alpha selfhosting pivot {#cmd-selfhosting} - -The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one. - -[Documentation](/docs/setup/production-environment/tools/kubeadm/self-hosting/) - -{{< tabs name="selfhosting" >}} -{{< tab name="selfhosting" include="generated/kubeadm_alpha_selfhosting.md" />}} -{{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}} -{{< /tabs >}} +Currently there are no experimental commands under `kubeadm alpha`. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md new file mode 100644 index 0000000000..f912285f7d --- /dev/null +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md @@ -0,0 +1,21 @@ +--- +title: kubeadm kubeconfig +content_type: concept +weight: 90 +--- + +`kubeadm kubeconfig` provides utilities for managing kubeconfig files. + +## kubeadm kubeconfig {#cmd-kubeconfig} + +{{< tabs name="tab-kubeconfig" >}} +{{< tab name="overview" include="generated/kubeadm_kubeconfig.md" />}} +{{< /tabs >}} + +## kubeadm kubeconfig user {#cmd-kubeconfig-user} + +This command can be used to output a kubeconfig file for an additional user. + +{{< tabs name="tab-kubeconfig-user" >}} +{{< tab name="user" include="generated/kubeadm_kubeconfig_user.md" />}} +{{< /tabs >}} \ No newline at end of file From dc75539de039b769e97add6144a56493cda20f62 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Thu, 21 Jan 2021 19:42:24 -0800 Subject: [PATCH 0004/1733] added German translation for pod overview --- .../de/docs/concepts/workloads/pods/_index.md | 372 ++++++++++++++++++ 1 file changed, 372 insertions(+) create mode 100644 content/de/docs/concepts/workloads/pods/_index.md diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md new file mode 100644 index 0000000000..d2a2009f8c --- /dev/null +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -0,0 +1,372 @@ +--- +reviewers: +- erictune +title: Pods +content_type: concept +weight: 10 +no_list: true +card: + name: concepts + weight: 60 +--- + + + +_Pods_ sind die kleinsten installierbaren Softwareeinheiten, die in Kubernetes +erstellt und verwaltet werden können. + +Ein _Pod_ (übersetzt Gruppe/Schote, wie z. B. eine Gruppe von Walen oder eine +Erbsenschote) ist eine Gruppe von einem oder mehreren +{{< glossary_tooltip text="Containern" term_id="container" >}} mit gemeinsam +genutzten Speicher- und Netzwerkressourcen und einer Spezifikation für die +Ausführung der Container. Die Ressourcen eines Pods befinden sich immer auf dem +gleichen (virtuellen) Server, werden gemeinsam geplant und in einem +gemeinsamen Kontext ausgeführt. Ein Pod modelliert einen anwendungsspezifischen +"logischen Server": Er enthält eine oder mehrere containerisierte Anwendungen +, die + relativ stark +voneinander abhängen. In Nicht-Cloud-Kontexten sind Anwendungen, die auf +demselben physischen oder virtuellen Server ausgeführt werden, vergleichbar zu +Cloud-Anwendungen, die auf demselben logischen Server ausgeführt werden. + +Ein Pod kann neben Anwendungs-Containern auch sogenannte +[Initialisierungs-Container](/docs/concepts/workloads/pods/init-containers/) +enthalten, die beim Starten des Pods ausgeführt werden. +Es können auch +kurzlebige/[ephemere Container](/docs/concepts/workloads/pods/ephemeral-containers/) +zum Debuggen gestartet werden, wenn dies der Cluster anbietet. + + + +## Was ist ein Pod? + +{{< note >}} +Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere +{{}} unterstützt, ist Docker am bekanntesten und + es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. +{{}} + +Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, +Cgroups und möglicherweise andere Aspekten der Isolation, also die gleichen +Dinge, die einen Dockercontainer isolieren. Innerhalb des Kontexts eines Pods +können die einzelnen Anwendungen weitere Unterisolierungen haben. + +Im Sinne von Docker-Konzepten ähnelt ein Pod einer Gruppe von Docker-Containern, +die gemeinsame Namespaces und Dateisystem-Volumes nutzen. + +## Pods verwenden + +Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. +Stattdessen werden sie mit Workload-Ressourcen wie {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. + +Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet: + +* **Pods, die einen einzelnen Container ausführen**. Das +"Ein-Container-per-Pod"-Modell ist der häufigste Kubernetes-Anwendungsfall. In +diesem Fall können Sie sich einen Pod als einen Behälter vorstellen, der einen +einzelnen Container enthält; Kubernetes verwaltet die Pods anstatt die +Container direkt zu verwalten. +* **Pods, in denen mehrere Container ausgeführt werden, die zusammenarbeiten +müssen**. Wenn eine Softwareanwendung aus co-lokaliserten Containern besteht, +die sich gemeinsame Ressourcen teilen und stark voneinander abhängen, kann ein +Pod die Container verkapseln. +Diese Container bilden eine einzelne zusammenhängende +Serviceeinheit, z. B. ein Container, der Daten in einem gemeinsam genutzten +Volume öffentlich verfügbar macht, während ein separater _Sidecar_-Container +die Daten aktualisiert. Der Pod fasst die Container, die Speicherressourcen +und eine kurzlebiges Netzwerk-Identität als eine Einheit zusammen. + +{{}} +Das Gruppieren mehrerer gemeinsam lokalisierter und gemeinsam verwalteter +Container in einem einzigen Pod ist ein relativ fortgeschrittener +Anwendungsfall. Sie sollten diese Architektur nur in bestimmten Fällen +verwenden, wenn Ihre Container stark voneinander abhängen. +{{}} + +Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn +Sie Ihre Anwendung horizontal skalieren wollen (also mehr Instanzen auszuführen +und dadurch mehr Gesamtressourcen bereitstellen), sollten Sie mehrere Pods +verwenden, +einen für jede Instanz. In Kubernetes wird dies typischerweise als Replikation +bezeichnet. +Replizierte Pods werden normalerweise als eine Gruppe von Workload-Ressource +und {{}} erstellt +und verwaltet. + +Die Seite [Pods und Controller](#pods-and-controllers) beschreibt, wie Kubernetes +Workload-Ressourcen und deren Controller verwendet, um Anwendungen zu skalieren +und zu heilen. + +### Wie Pods mehrere Container verwalten + +Pods unterstützen mehrere kooperierende Prozesse (als Container), die eine +zusammenhängende Serviceeinheit bilden. Kubernetes plant und stellt automatisch +sicher, dass sich die Container in einem Pod auf demselben physischen oder +virtuellen Server im Cluster befinden. Die Container können Ressourcen und +Abhängigkeiten gemeinsam nutzen, miteinander kommunizieren und +ferner koordinieren wann und wie sie beendet werden. + +Zum Beispiel könnten Sie einen Container haben, der als Webserver für Dateien in +einem gemeinsamen Volume arbeitet. Und ein separater "Sidecar" -Container +aktualisiert die Daten von einer externen Datenquelle, siehe folgenden +Abbildung: + +{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} + +Einige Pods haben sowohl {{}} als auch {{}}. +Initialisierungs-Container werden gestartet und angehalten bevor die +Anwendungs-Container gestartet werden. + +Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die +enthaltenen Container bereit: +[Netzwerk](#pod-networking) und [Speicher](#pod-storage).. + + +## Mit Pods arbeiten + +Sie werden selten einzelne Pods direkt in Kubernetes erstellen, selbst +Singleton-Pods. Das liegt daran, dass Pods als relativ kurzlebige +Einweg-Einheiten konzipiert sind. Wann Ein Pod erstellt wird (entweder direkt +von Ihnen oder indirekt von einem +{{}}), wird die +Ausführung auf einem {{}} in Ihrem Cluster +geplant. Der Pod bleibt auf diesem (virtuellen) Server, bis entweder der Pod die +Ausführung beendet hat, das Pod-Objekt gelöscht wird, der Pod aufgrund +mangelnder Ressourcen *evakuiert* wird oder oder der Node ausfällt. + +{{}} +Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten +eines Pods verwechselt werden. Ein Pod ist kein Prozess, sondern eine Umgebung +zur Ausführung von Containern. Ein Pod bleibt bestehen bis er gelöscht wird. +{{}} + +Stellen Sie beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der +angegebene Name ein gültiger +[DNS-Subdomain-Name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) +ist. + +### Pods und Controller + +Mit Workload-Ressourcen können Sie mehrere Pods erstellen und verwalten. Ein +Controller für die Ressource kümmert sich um Replikation, Roll-Out sowie +automatische Heilung im Fall von Podfehlern. Wenn beispielsweise ein Node +ausfällt, bemerkt ein Controller, dass die Pods auf dem Node nicht mehr laufen +und plant die Ausführung eines Ersatzpods auf einem funktionierenden Node. +Hier sind einige Beispiele für Workload-Ressourcen, die einen oder mehrere Pods +verwalten: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Podvorlagen + +Controller für +{{}}-Ressourcen +erstellen Pods von einer _Podvorlage_ und verwalten diese Pods für sie. + +Podvorlagen sind Spezifikationen zum Erstellen von Pods und sind in +Workload-Ressourcen enthalten wie z. B. +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/workloads/controllers/job/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Jeder Controller für eine Workload-Ressource verwendet die Podvorlage innerhalb +des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Bestandteil des +gewünschten Zustands der Workload-Ressource, mit der Sie Ihre Anwendung +ausgeführt haben. + +Das folgende Beispiel ist ein Manifest für einen einfachen Job mit einer +`Vorlage`, die einen Container startet. Der Container in diesem Pod druckt +eine Nachricht und pausiert dann. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # This is the pod template + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # The pod template ends here +``` +Das Ändern der Podvorlage oder der Wechsel zu einer neuen Podvorlage hat keine +direkten Auswirkungen auf bereits existierende Pods. Wenn Sie die Podvorlage für +eine Workload-Ressource ändern, dann muss diese Ressource die Ersatz-Pods +erstellen, welche die aktualisierte Vorlage verwenden. + +Beispielsweise stellt der StatefulSet-Controller sicher, dass für jedes +StatefulSet-Objekt die ausgeführten Pods mit der aktueller Podvorlage +übereinstimmen. Wenn Sie das StatefulSet bearbeiten und die Vorlage ändern, +beginnt das StatefulSet mit der Erstellung neuer Pods basierend auf der +aktualisierten Vorlage. Schließlich werden alle alten Pods durch neue Pods +ersetzt, und das Update ist abgeschlossen. + +Jede Workload-Ressource implementiert eigenen Regeln für die Umsetzung von +Änderungen der Podvorlage. Wenn Sie mehr über StatefulSet erfahren möchten, +lesen Sie +[Update strategy](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) +im Tutorial StatefulSet Basics. + + +Auf Nodes beobachtet oder verwaltet das +{{< glossary_tooltip term_id="kubelet" text="Kubelet" >}} +nicht direkt die Details zu Podvorlagen und Updates. Diese Details sind +abstrahiert. Die Abstraktion und Trennung von Aufgaben vereinfacht die +Systemsemantik und ermöglicht so das Verhalten des Clusters zu ändern ohne +vorhandenen Code zu ändern. + +## Pod Update und Austausch + +Wie im vorherigen Abschnitt erwähnt, erstellt der Controller neue Pods basierend +auf der aktualisierten Vorlage, wenn die Podvorlage für eine Workload-Ressource +geändert wird anstatt die vorhandenen Pods zu aktualisieren oder zu patchen. + +Kubernetes hindert Sie nicht daran, Pods direkt zu verwalten. Es ist möglich, +einige Felder eines laufenden Pods zu aktualisieren. Allerdings haben +Pod-Aktualisierungsvorgänge wie zum Beispiel +[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), +und +[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core) +einige Einschränkungen: + +- Die meisten Metadaten zu einem Pod sind unveränderlich. Zum Beispiel können + Sie nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` + ändern. Das `generation`-Feld ist eindeutig. Es werden nur Aktualisierungen + akzeptiert, die den Wert des Feldes inkrementieren. +- Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer + Eintrag zur Liste `metadata.finalizers` hinzugefügt werden. +- Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind + `spec.containers [*].image`, + `spec.initContainers [*].image`,` spec.activeDeadlineSeconds` oder + `spec.tolerations`. Für `spec.tolerations` können Sie nur neue Einträge + hinzufügen. +- Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt: + + 1. ungesetztes Feld in eine positive Zahl + 1. positive Zahl in eine kleinere positive Zahl, die nicht negativ ist + +## Gemeinsame Nutzung von Ressourcen und Kommunikation + +Pods ermöglichen den Datenaustausch und die Kommunikation zwischen den +Containern, die im Pod enthalten sind. + +### Datenspeicherung in Pods {#pod-storage} + +Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- +{{}} spezifizieren. Alle +Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten +austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert +werden, falls einer der Container neu gestartet werden muss. +Im Kapitel [Datenspeicherung](/docs/concepts/storage/) finden Sie weitere +Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und Pods +zur Verfügung stellt. + +### Pod-Netzwerk + +Jedem Pod wird für jede Adressenfamilie eine eindeutige IP-Adresse zugewiesen. +Jeder Container in einem Pod nutzt den gemeinsamen Netzwerk-Namespace, +einschließlich der IP-Adresse und der Ports. In einem Pod (und **nur** dann) +können die Container, die zum Pod gehören, über `localhost` miteinander +kommunizieren. Wenn Container in einem Pod mit Entitäten *außerhalb des Pods* +kommunizieren, müssen sie koordinieren, wie die gemeinsam genutzten +Netzwerkressourcen (z. B. Ports) verwenden werden. Innerhalb eines Pods teilen +sich Container eine IP-Adresse und einen Reihe von Ports und können sich +gegenseitig über `localhost` finden. Die Container in einem Pod können auch die +üblichen Kommunikationsverfahren zwischen Prozessen nutzen, wie z. B. +SystemV-Semaphoren oder POSIX Shared Memory. Container in verschiedenen Pods +haben unterschiedliche IP-Adressen und können nicht per IPC ohne +[spezielle Konfiguration](/docs/concepts/policy/pod-security-policy/) +kommunizieren. Container, die mit einem Container in einem anderen Pod +interagieren möchten, müssen IP Netzwerke verwenden. + +Für die Container innerhalb eines Pods stimmt der "hostname" mit dem +konfigurierten `Namen` des Pods überein. Mehr dazu im Kapitel +[Netzwerke](/docs/concepts/cluster-administration/networking/). + +## Privilegierter Modus für Container + +Jeder Container in einem Pod kann den privilegierten Modus aktivieren, indem +das Flag `privileged` im +[Sicherheitskontext](/docs/tasks/configure-pod-container/security-context/) +der Container-Spezifikation verwendet wird. +Dies ist nützlich für Container, die Verwaltungsfunktionen des Betriebssystems +verwenden möchten, z. B. das Manipulieren des Netzwerk-Stacks oder den Zugriff +auf Hardware. Prozesse innerhalb eines privilegierten Containers erhalten fast +die gleichen Rechte wie sie Prozesse außerhalb eines Containers zur Verfügung +stehen. + +{{}} +Ihre +{{}} +muss das Konzept eines privilegierten Containers unterstützen, damit diese +Einstellung relevant ist. +{{}} + + +## Statische Pods + +_Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node +verwaltet ohne dass sie vom +{{}} überwacht +werden. +. +Die meisten Pods werden von der Control Plane verwaltet (z. B. +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}). Aber für +statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet +ihn neu, wenn er ausfällt). + +Statische Pods sind immer an ein {{}} auf +einem bestimmten Node gebunden. Der Hauptanwendungsfall für statische Pods +besteht darin, eine selbst gehostete Steuerebene auszuführen. Mit anderen +Worten: Das Kubelet dient zur Überwachung der einzelnen +[control plane components](/docs/concepts/overview/components/#control-plane-components). + +Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden +statischen Pod einen spiegelbildlichen Pod +(im Englischen {{}}) +zu erstellen. +Das bedeutet, dass die auf einem Node ausgeführten Pods auf dem API-Server +sichtbar sind jedoch von dort nicht gesteuert werden können. + +## {{% heading "whatsnext" %}} + +* Erfahren Sie mehr über den + [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/). +* Erfahren Sie mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) + und wie Sie damit verschiedene Pods mit unterschiedlichen + Container-Laufzeitumgebung konfigurieren können. +* Lesen sie mehr über + [Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Lesen sie mehr über sogenannte + [Pod-Disruption-Budgets](/docs/concepts/workloads/pods/disruptions/) + und wie Sie diese verwenden können, um die Verfügbarkeit von Anwendungen bei + Störungen zu verwalten. Die + [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + -Objektdefinition beschreibt das Objekt im Detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) + erläutert allgemeine Layouts für Pods mit mehr als einem Container. + +Um den Hintergrund zu verstehen, warum Kubernetes eine gemeinsame Pod-API in +andere Ressourcen, wie z. B. +{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} +oder {{< glossary_tooltip text="Deployments" term_id="deployment" >}} einbindet, +können sie Artikel zu früheren Technologien lesen, unter anderem: + * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). \ No newline at end of file From f213353b3028d6fc8099b7232346321a5f63ed66 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Thu, 21 Jan 2021 20:45:13 -0800 Subject: [PATCH 0005/1733] added German translation for pod overview page --- .../de/docs/concepts/workloads/pods/_index.md | 49 ++++++++++--------- 1 file changed, 25 insertions(+), 24 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index d2a2009f8c..b1aec877c9 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -12,7 +12,7 @@ card: -_Pods_ sind die kleinsten installierbaren Softwareeinheiten, die in Kubernetes +_Pods_ sind die kleinsten einsetzbaren Einheiten, die in Kubernetes erstellt und verwaltet werden können. Ein _Pod_ (übersetzt Gruppe/Schote, wie z. B. eine Gruppe von Walen oder eine @@ -42,13 +42,13 @@ zum Debuggen gestartet werden, wenn dies der Cluster anbietet. {{< note >}} Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere -{{}} unterstützt, ist Docker am bekanntesten und es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. {{}} Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, -Cgroups und möglicherweise andere Aspekten der Isolation, also die gleichen +Cgroups und möglicherweise anderen Aspekten der Isolation, also die gleichen Dinge, die einen Dockercontainer isolieren. Innerhalb des Kontexts eines Pods können die einzelnen Anwendungen weitere Unterisolierungen haben. @@ -89,18 +89,19 @@ verwenden, wenn Ihre Container stark voneinander abhängen. {{}} Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn -Sie Ihre Anwendung horizontal skalieren wollen (also mehr Instanzen auszuführen +Sie Ihre Anwendung horizontal skalieren wollen (um mehr Instanzen auszuführen und dadurch mehr Gesamtressourcen bereitstellen), sollten Sie mehrere Pods verwenden, einen für jede Instanz. In Kubernetes wird dies typischerweise als Replikation bezeichnet. -Replizierte Pods werden normalerweise als eine Gruppe von Workload-Ressource -und {{}} erstellt +Replizierte Pods werden normalerweise als eine Gruppe durch eine +Workload-Ressource und deren +{{}} erstellt und verwaltet. -Die Seite [Pods und Controller](#pods-and-controllers) beschreibt, wie Kubernetes -Workload-Ressourcen und deren Controller verwendet, um Anwendungen zu skalieren -und zu heilen. +Die Seite [Pods und Controller](#pods-and-controllers) beschreibt, wie +Kubernetes Workload-Ressourcen und deren Controller verwendet, um Anwendungen +zu skalieren und zu heilen. ### Wie Pods mehrere Container verwalten @@ -121,12 +122,12 @@ Abbildung: Einige Pods haben sowohl {{}} als auch {{}}. -Initialisierungs-Container werden gestartet und angehalten bevor die +Initialisierungs-Container werden gestartet und beendet bevor die Anwendungs-Container gestartet werden. Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die enthaltenen Container bereit: -[Netzwerk](#pod-networking) und [Speicher](#pod-storage).. +[Netzwerk](#pod-networking) und [Speicher](#pod-storage). ## Mit Pods arbeiten @@ -179,7 +180,7 @@ Workload-Ressourcen enthalten wie z. B. [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). Jeder Controller für eine Workload-Ressource verwendet die Podvorlage innerhalb -des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Bestandteil des +des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Teil des gewünschten Zustands der Workload-Ressource, mit der Sie Ihre Anwendung ausgeführt haben. @@ -217,8 +218,8 @@ ersetzt, und das Update ist abgeschlossen. Jede Workload-Ressource implementiert eigenen Regeln für die Umsetzung von Änderungen der Podvorlage. Wenn Sie mehr über StatefulSet erfahren möchten, -lesen Sie -[Update strategy](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) +lesen Sie die Seite +[Update-Strategien](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) im Tutorial StatefulSet Basics. @@ -243,9 +244,9 @@ und [`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core) einige Einschränkungen: -- Die meisten Metadaten zu einem Pod sind unveränderlich. Zum Beispiel können +- Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel können Sie nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` - ändern. Das `generation`-Feld ist eindeutig. Es werden nur Aktualisierungen + ändern. Das `generation`-Feld muss eindeutig sein. Es werden nur Aktualisierungen akzeptiert, die den Wert des Feldes inkrementieren. - Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer Eintrag zur Liste `metadata.finalizers` hinzugefügt werden. @@ -272,8 +273,8 @@ Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert werden, falls einer der Container neu gestartet werden muss. Im Kapitel [Datenspeicherung](/docs/concepts/storage/) finden Sie weitere -Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und Pods -zur Verfügung stellt. +Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und +Pods zur Verfügung stellt. ### Pod-Netzwerk @@ -284,10 +285,10 @@ können die Container, die zum Pod gehören, über `localhost` miteinander kommunizieren. Wenn Container in einem Pod mit Entitäten *außerhalb des Pods* kommunizieren, müssen sie koordinieren, wie die gemeinsam genutzten Netzwerkressourcen (z. B. Ports) verwenden werden. Innerhalb eines Pods teilen -sich Container eine IP-Adresse und einen Reihe von Ports und können sich +sich Container eine IP-Adresse und eine Reihe von Ports und können sich gegenseitig über `localhost` finden. Die Container in einem Pod können auch die üblichen Kommunikationsverfahren zwischen Prozessen nutzen, wie z. B. -SystemV-Semaphoren oder POSIX Shared Memory. Container in verschiedenen Pods +SystemV-Semaphoren oder "POSIX Shared Memory". Container in verschiedenen Pods haben unterschiedliche IP-Adressen und können nicht per IPC ohne [spezielle Konfiguration](/docs/concepts/policy/pod-security-policy/) kommunizieren. Container, die mit einem Container in einem anderen Pod @@ -306,7 +307,7 @@ der Container-Spezifikation verwendet wird. Dies ist nützlich für Container, die Verwaltungsfunktionen des Betriebssystems verwenden möchten, z. B. das Manipulieren des Netzwerk-Stacks oder den Zugriff auf Hardware. Prozesse innerhalb eines privilegierten Containers erhalten fast -die gleichen Rechte wie sie Prozesse außerhalb eines Containers zur Verfügung +die gleichen Rechte wie sie Prozessen außerhalb eines Containers zur Verfügung stehen. {{}} @@ -324,7 +325,7 @@ verwaltet ohne dass sie vom {{}} überwacht werden. . -Die meisten Pods werden von der Control Plane verwaltet (z. B. +Die meisten Pods werden von der Kontrollebene verwaltet (z. B. {{< glossary_tooltip text="Deployment" term_id="deployment" >}}). Aber für statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet ihn neu, wenn er ausfällt). @@ -333,7 +334,7 @@ Statische Pods sind immer an ein {{}} auf einem bestimmten Node gebunden. Der Hauptanwendungsfall für statische Pods besteht darin, eine selbst gehostete Steuerebene auszuführen. Mit anderen Worten: Das Kubelet dient zur Überwachung der einzelnen -[control plane components](/docs/concepts/overview/components/#control-plane-components). +[Komponenten der Kontrollebene](/docs/concepts/overview/components/#control-plane-components). Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden statischen Pod einen spiegelbildlichen Pod @@ -348,7 +349,7 @@ sichtbar sind jedoch von dort nicht gesteuert werden können. [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/). * Erfahren Sie mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) und wie Sie damit verschiedene Pods mit unterschiedlichen - Container-Laufzeitumgebung konfigurieren können. + Container-Laufzeitumgebungen konfigurieren können. * Lesen sie mehr über [Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). * Lesen sie mehr über sogenannte From 90cc7f10d4413ebbb1a33f0624138fb862e9d864 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Tue, 2 Feb 2021 22:20:15 -0800 Subject: [PATCH 0006/1733] changes suggested by code reviewer --- .../de/docs/concepts/workloads/pods/_index.md | 67 +++++++++---------- 1 file changed, 32 insertions(+), 35 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index b1aec877c9..4080f460f9 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -1,6 +1,4 @@ --- -reviewers: -- erictune title: Pods content_type: concept weight: 10 @@ -22,10 +20,9 @@ genutzten Speicher- und Netzwerkressourcen und einer Spezifikation für die Ausführung der Container. Die Ressourcen eines Pods befinden sich immer auf dem gleichen (virtuellen) Server, werden gemeinsam geplant und in einem gemeinsamen Kontext ausgeführt. Ein Pod modelliert einen anwendungsspezifischen -"logischen Server": Er enthält eine oder mehrere containerisierte Anwendungen -, die - relativ stark -voneinander abhängen. In Nicht-Cloud-Kontexten sind Anwendungen, die auf +"logischen Server": Er enthält eine oder mehrere containerisierte Anwendungen, +die relativ stark voneinander abhängen. +In Nicht-Cloud-Kontexten sind Anwendungen, die auf demselben physischen oder virtuellen Server ausgeführt werden, vergleichbar zu Cloud-Anwendungen, die auf demselben logischen Server ausgeführt werden. @@ -42,10 +39,10 @@ zum Debuggen gestartet werden, wenn dies der Cluster anbietet. {{< note >}} Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere -{{}} unterstützt, ist Docker am bekanntesten und +{{}} unterstützt, ist Docker am bekanntesten und es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. -{{}} +{{< /note >}} Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, Cgroups und möglicherweise anderen Aspekten der Isolation, also die gleichen @@ -59,10 +56,10 @@ die gemeinsame Namespaces und Dateisystem-Volumes nutzen. Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. Stattdessen werden sie mit Workload-Ressourcen wie {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand -abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. +text="Deployment" term_id="deployment">}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet: @@ -81,12 +78,12 @@ Volume öffentlich verfügbar macht, während ein separater _Sidecar_-Container die Daten aktualisiert. Der Pod fasst die Container, die Speicherressourcen und eine kurzlebiges Netzwerk-Identität als eine Einheit zusammen. -{{}} +{{< note >}} Das Gruppieren mehrerer gemeinsam lokalisierter und gemeinsam verwalteter Container in einem einzigen Pod ist ein relativ fortgeschrittener Anwendungsfall. Sie sollten diese Architektur nur in bestimmten Fällen verwenden, wenn Ihre Container stark voneinander abhängen. -{{}} +{{< /note >}} Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn Sie Ihre Anwendung horizontal skalieren wollen (um mehr Instanzen auszuführen @@ -96,10 +93,10 @@ einen für jede Instanz. In Kubernetes wird dies typischerweise als Replikation bezeichnet. Replizierte Pods werden normalerweise als eine Gruppe durch eine Workload-Ressource und deren -{{}} erstellt +{{}} erstellt und verwaltet. -Die Seite [Pods und Controller](#pods-and-controllers) beschreibt, wie +Der Abschnitt [Pods und Controller](#pods-und-controller) beschreibt, wie Kubernetes Workload-Ressourcen und deren Controller verwendet, um Anwendungen zu skalieren und zu heilen. @@ -117,17 +114,17 @@ einem gemeinsamen Volume arbeitet. Und ein separater "Sidecar" -Container aktualisiert die Daten von einer externen Datenquelle, siehe folgenden Abbildung: -{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} +{{< figure src="/images/docs/pod.svg" alt="Pod-Beispieldiagramm" width="50%" >}} -Einige Pods haben sowohl {{}} als auch {{}}. +Einige Pods haben sowohl {{}} als auch {{}}. Initialisierungs-Container werden gestartet und beendet bevor die Anwendungs-Container gestartet werden. Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die enthaltenen Container bereit: -[Netzwerk](#pod-networking) und [Speicher](#pod-storage). +[Netzwerk](#pod-netzwerk) und [Speicher](#datenspeicherung-in-pods). ## Mit Pods arbeiten @@ -136,17 +133,17 @@ Sie werden selten einzelne Pods direkt in Kubernetes erstellen, selbst Singleton-Pods. Das liegt daran, dass Pods als relativ kurzlebige Einweg-Einheiten konzipiert sind. Wann Ein Pod erstellt wird (entweder direkt von Ihnen oder indirekt von einem -{{}}), wird die -Ausführung auf einem {{}} in Ihrem Cluster +{{}}), wird die +Ausführung auf einem {{}} in Ihrem Cluster geplant. Der Pod bleibt auf diesem (virtuellen) Server, bis entweder der Pod die Ausführung beendet hat, das Pod-Objekt gelöscht wird, der Pod aufgrund mangelnder Ressourcen *evakuiert* wird oder oder der Node ausfällt. -{{}} +{{< note >}} Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten eines Pods verwechselt werden. Ein Pod ist kein Prozess, sondern eine Umgebung zur Ausführung von Containern. Ein Pod bleibt bestehen bis er gelöscht wird. -{{}} +{{< /note >}} Stellen Sie beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der angegebene Name ein gültiger @@ -170,7 +167,7 @@ verwalten: ### Podvorlagen Controller für -{{}}-Ressourcen +{{}}-Ressourcen erstellen Pods von einer _Podvorlage_ und verwalten diese Pods für sie. Podvorlagen sind Spezifikationen zum Erstellen von Pods und sind in @@ -265,10 +262,10 @@ einige Einschränkungen: Pods ermöglichen den Datenaustausch und die Kommunikation zwischen den Containern, die im Pod enthalten sind. -### Datenspeicherung in Pods {#pod-storage} +### Datenspeicherung in Pods Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- -{{}} spezifizieren. Alle +{{}} spezifizieren. Alle Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert werden, falls einer der Container neu gestartet werden muss. @@ -310,19 +307,19 @@ auf Hardware. Prozesse innerhalb eines privilegierten Containers erhalten fast die gleichen Rechte wie sie Prozessen außerhalb eines Containers zur Verfügung stehen. -{{}} +{{< note >}} Ihre -{{}} +{{}} muss das Konzept eines privilegierten Containers unterstützen, damit diese Einstellung relevant ist. -{{}} +{{< /note >}} ## Statische Pods _Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node verwaltet ohne dass sie vom -{{}} überwacht +{{}} überwacht werden. . Die meisten Pods werden von der Kontrollebene verwaltet (z. B. @@ -330,7 +327,7 @@ Die meisten Pods werden von der Kontrollebene verwaltet (z. B. statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet ihn neu, wenn er ausfällt). -Statische Pods sind immer an ein {{}} auf +Statische Pods sind immer an ein {{}} auf einem bestimmten Node gebunden. Der Hauptanwendungsfall für statische Pods besteht darin, eine selbst gehostete Steuerebene auszuführen. Mit anderen Worten: Das Kubelet dient zur Überwachung der einzelnen @@ -338,7 +335,7 @@ Worten: Das Kubelet dient zur Überwachung der einzelnen Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden statischen Pod einen spiegelbildlichen Pod -(im Englischen {{}}) +(im Englischen: {{}}) zu erstellen. Das bedeutet, dass die auf einem Node ausgeführten Pods auf dem API-Server sichtbar sind jedoch von dort nicht gesteuert werden können. From 99aa654d8be21ab928177a05a70514d586abd030 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Tue, 2 Feb 2021 22:53:55 -0800 Subject: [PATCH 0007/1733] changes suggested by code reviewer, part 2 --- content/de/docs/concepts/workloads/pods/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index 4080f460f9..837a1f1571 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -192,14 +192,14 @@ metadata: name: hello spec: template: - # This is the pod template + # Dies is the Podvorlage spec: containers: - name: hello image: busybox command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure - # The pod template ends here + # Die Podvorlage endet hier ``` Das Ändern der Podvorlage oder der Wechsel zu einer neuen Podvorlage hat keine direkten Auswirkungen auf bereits existierende Pods. Wenn Sie die Podvorlage für @@ -248,8 +248,8 @@ einige Einschränkungen: - Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer Eintrag zur Liste `metadata.finalizers` hinzugefügt werden. - Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind - `spec.containers [*].image`, - `spec.initContainers [*].image`,` spec.activeDeadlineSeconds` oder + `spec.containers[*].image`, + `spec.initContainers[*].image`,` spec.activeDeadlineSeconds` oder `spec.tolerations`. Für `spec.tolerations` können Sie nur neue Einträge hinzufügen. - Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt: From c111b4ac6221ae8674e9b7c2303701a1c30c75f0 Mon Sep 17 00:00:00 2001 From: Tim Hockin Date: Fri, 29 Jan 2021 15:12:40 -0800 Subject: [PATCH 0008/1733] Docs for KEP 2200 * Document DenyServiceExternalIPs admission controller * Re-order other admission controller blocks to be alphabetical * Document DefaultIngressClass (missing) --- .../admission-controllers.md | 133 +++++++++++------- .../kube-apiserver.md | 2 +- 2 files changed, 82 insertions(+), 53 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 0cdcbf2f36..edb1f5403e 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -94,7 +94,7 @@ kube-apiserver -h | grep enable-admission-plugins In the current version, the default ones are: ```shell -NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota +CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook ``` ## What does each admission controller do? @@ -105,6 +105,12 @@ NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority This admission controller allows all pods into the cluster. It is deprecated because its behavior is the same as if there were no admission controller at all. +### AlwaysDeny {#alwaysdeny} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} + +Rejects all requests. AlwaysDeny is DEPRECATED as it has no real meaning. + ### AlwaysPullImages {#alwayspullimages} This admission controller modifies every new Pod to force the image pull policy to Always. This is useful in a @@ -115,12 +121,6 @@ scheduled onto the right node), without any authorization check against the imag is enabled, images are always pulled prior to starting containers, which means valid credentials are required. -### AlwaysDeny {#alwaysdeny} - -{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - -Rejects all requests. AlwaysDeny is DEPRECATED as no real meaning. - ### CertificateApproval {#certificateapproval} This admission controller observes requests to 'approve' CertificateSigningRequest resources and performs additional @@ -145,6 +145,22 @@ This admission controller observes creation of CertificateSigningRequest resourc of `kubernetes.io/kube-apiserver-client`. It rejects any request that specifies a 'group' (or 'organization attribute') of `system:masters`. +### DefaultIngressClass {#defaultingressclass} + +This admission controller observes creation of `Ingress` objects that do not request any specific +ingress class and automatically adds a default ingress class to them. This way, users that do not +request any special ingress class do not need to care about them at all and they will get the +default one. + +This admission controller does not do anything when no default ingress class is configured. When more than one ingress +class is marked as default, it rejects any creation of `Ingress` with an error and an administrator +must revisit their `IngressClass` objects and mark only one as default (with the annotation +"ingressclass.kubernetes.io/is-default-class"). This admission controller ignores any `Ingress` +updates; it acts only on creation. + +See the [ingress](/docs/concepts/services-networking/ingress/) documentation for more about ingress +classes and how to mark one as default. + ### DefaultStorageClass {#defaultstorageclass} This admission controller observes creation of `PersistentVolumeClaim` objects that do not request any specific storage class @@ -169,19 +185,6 @@ have toleration for taints `node.kubernetes.io/not-ready:NoExecute` or `node.kubernetes.io/unreachable:NoExecute`. The default value for `default-not-ready-toleration-seconds` and `default-unreachable-toleration-seconds` is 5 minutes. -### DenyExecOnPrivileged {#denyexeconprivileged} - -{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} - -This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container. - -This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec). -The DenyExecOnPrivileged admission plugin is deprecated and will be removed in v1.18. - -Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin) -which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods -is recommended instead. - ### DenyEscalatingExec {#denyescalatingexec} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} @@ -190,12 +193,38 @@ This admission controller will deny exec and attach commands to pods that run wi allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. -The DenyEscalatingExec admission plugin is deprecated and will be removed in v1.18. +The DenyEscalatingExec admission plugin is deprecated and will be removed in v1.21. Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin) which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods is recommended instead. +### DenyExecOnPrivileged {#denyexeconprivileged} + +{{< feature-state for_k8s_version="v1.13" state="deprecated" >}} + +This admission controller will intercept all requests to exec a command in a pod if that pod has a privileged container. + +This functionality has been merged into [DenyEscalatingExec](#denyescalatingexec). +The DenyExecOnPrivileged admission plugin is deprecated and will be removed in v1.21. + +Use of a policy-based admission plugin (like [PodSecurityPolicy](#podsecuritypolicy) or a custom admission plugin) +which can be targeted at specific users or Namespaces and also protects against creation of overly privileged Pods +is recommended instead. + +### DenyServiceExternalIPs + +This admission controller rejects all net-new usage of the `Service` field `externalIPs`. This +feature is very powerful (allows network traffic interception) and not well +controlled by policy. When enabled, users of the cluster may not create new +Services which use `externalIPs` and may not add new values to `externalIPs` on +existing `Service` objects. Existing uses of `externalIPs` are not affected, +and users may remove values from `externalIPs` on existing `Service` objects. + +Most users do not need this feature at all, and cluster admins should consider disabling it. +Clusters that do need to use this feature should consider using some custom policy to manage usage +of it. + ### EventRateLimit {#eventratelimit} {{< feature-state for_k8s_version="v1.13" state="alpha" >}} @@ -553,6 +582,37 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. +### PersistentVolumeClaimResize {#persistentvolumeclaimresize} + +This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests. + +{{< note >}} +Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes` +to `true` to enable resizing. +{{< /note >}} + +After enabling the `ExpandPersistentVolumes` feature gate, enabling the `PersistentVolumeClaimResize` admission +controller is recommended, too. This admission controller prevents resizing of all claims by default unless a claim's `StorageClass` + explicitly enables resizing by setting `allowVolumeExpansion` to `true`. + +For example: all `PersistentVolumeClaim`s created from the following `StorageClass` support volume expansion: + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: gluster-vol-default +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://192.168.10.100:8080" + restuser: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). + ### PersistentVolumeLabel {#persistentvolumelabel} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} @@ -638,37 +698,6 @@ PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also s admission plugin, which allows preventing pods from running on specifically tainted nodes. {{< /note >}} -### PersistentVolumeClaimResize {#persistentvolumeclaimresize} - -This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests. - -{{< note >}} -Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes` -to `true` to enable resizing. -{{< /note >}} - -After enabling the `ExpandPersistentVolumes` feature gate, enabling the `PersistentVolumeClaimResize` admission -controller is recommended, too. This admission controller prevents resizing of all claims by default unless a claim's `StorageClass` - explicitly enables resizing by setting `allowVolumeExpansion` to `true`. - -For example: all `PersistentVolumeClaim`s created from the following `StorageClass` support volume expansion: - -```yaml -apiVersion: storage.k8s.io/v1 -kind: StorageClass -metadata: - name: gluster-vol-default -provisioner: kubernetes.io/glusterfs -parameters: - resturl: "http://192.168.10.100:8080" - restuser: "" - secretNamespace: "" - secretName: "" -allowVolumeExpansion: true -``` - -For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). - ### PodSecurityPolicy {#podsecuritypolicy} This admission controller acts on creation and modification of the pod and determines if it should be admitted diff --git a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md index 6e87bff44c..73ef70c81b 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -470,7 +470,7 @@ kube-apiserver [flags] - + From 507dc0aa20ca08307880a00e2a8322e80ba9bd9c Mon Sep 17 00:00:00 2001 From: wojtekt Date: Fri, 12 Feb 2021 11:41:55 +0100 Subject: [PATCH 0009/1733] Promote immutable secrets and configmaps to GA --- content/en/docs/concepts/configuration/configmap.md | 4 ++-- content/en/docs/concepts/configuration/secret.md | 4 ++-- .../reference/command-line-tools-reference/feature-gates.md | 5 +++-- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index 9a134dfc99..d0195e6bd9 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -235,9 +235,9 @@ propagation delay, where the cache propagation delay depends on the chosen cache ConfigMaps consumed as environment variables are not updated automatically and require a pod restart. ## Immutable ConfigMaps {#configmap-immutable} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set +The Kubernetes feature _Immutable Secrets and ConfigMaps_ provides an option to set individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps (at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their data has the following advantages: diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 5a6a0dd092..ab627ce056 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -749,9 +749,9 @@ There are third party solutions for triggering restarts when secrets change. ## Immutable Secrets {#secret-immutable} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set +The Kubernetes feature _Immutable Secrets and ConfigMaps_ provides an option to set individual Secrets and ConfigMaps as immutable. For clusters that extensively use Secrets (at least tens of thousands of unique Secret to Pod mounts), preventing changes to their data has the following advantages: diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index d9754afb56..bc5f066d73 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -124,8 +124,6 @@ different Kubernetes components. | `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 | | `HugePageStorageMediumSize` | `true` | Beta | 1.19 | | | `IPv6DualStack` | `false` | Alpha | 1.15 | | -| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 | -| `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | | | `KubeletPodResources` | `true` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | @@ -257,6 +255,9 @@ different Kubernetes components. | `HugePages` | `true` | GA | 1.14 | - | | `HyperVContainer` | `false` | Alpha | 1.10 | 1.19 | | `HyperVContainer` | `false` | Deprecated | 1.20 | - | +| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 | +| `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | 1.20 | +| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | | | `Initializers` | `false` | Alpha | 1.7 | 1.13 | | `Initializers` | - | Deprecated | 1.14 | - | | `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 | From f65f808fb2a455af9244ecce9853b091c740202f Mon Sep 17 00:00:00 2001 From: Tim Allclair Date: Tue, 16 Feb 2021 11:25:43 -0800 Subject: [PATCH 0010/1733] Mark PSP deprecated in the docs --- content/en/docs/concepts/policy/pod-security-policy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index f355a8f539..f0884c3dea 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -9,7 +9,9 @@ weight: 30 -{{< feature-state state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. Pod Security Policies enable fine-grained authorization of pod creation and updates. From 5b127f07612d45ba0a142370e4e58f9e859c3830 Mon Sep 17 00:00:00 2001 From: flo-oss Date: Tue, 16 Feb 2021 21:07:07 -0800 Subject: [PATCH 0011/1733] changes suggested by code reviewer (sie -> du, Pod Vorlage, ....) --- .../de/docs/concepts/workloads/pods/_index.md | 97 +++++++++---------- 1 file changed, 48 insertions(+), 49 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index 837a1f1571..e6adce49a6 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -57,15 +57,15 @@ die gemeinsame Namespaces und Dateisystem-Volumes nutzen. Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. Stattdessen werden sie mit Workload-Ressourcen wie {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand -abhängen, erwägen Sie die Nutzung von {{}}-Ressourcen. +text="Job" term_id="job">}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, ist die Nutzung von {{}}-Ressourcen zu erwägen. Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet: * **Pods, die einen einzelnen Container ausführen**. Das "Ein-Container-per-Pod"-Modell ist der häufigste Kubernetes-Anwendungsfall. In -diesem Fall können Sie sich einen Pod als einen Behälter vorstellen, der einen +diesem Fall kannst du dir einen einen Pod als einen Behälter vorstellen, der einen einzelnen Container enthält; Kubernetes verwaltet die Pods anstatt die Container direkt zu verwalten. * **Pods, in denen mehrere Container ausgeführt werden, die zusammenarbeiten @@ -81,16 +81,15 @@ und eine kurzlebiges Netzwerk-Identität als eine Einheit zusammen. {{< note >}} Das Gruppieren mehrerer gemeinsam lokalisierter und gemeinsam verwalteter Container in einem einzigen Pod ist ein relativ fortgeschrittener -Anwendungsfall. Sie sollten diese Architektur nur in bestimmten Fällen -verwenden, wenn Ihre Container stark voneinander abhängen. +Anwendungsfall. Du solltest diese Architektur nur in bestimmten Fällen +verwenden, wenn deine Container stark voneinander abhängen. {{< /note >}} Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn -Sie Ihre Anwendung horizontal skalieren wollen (um mehr Instanzen auszuführen -und dadurch mehr Gesamtressourcen bereitstellen), sollten Sie mehrere Pods -verwenden, -einen für jede Instanz. In Kubernetes wird dies typischerweise als Replikation -bezeichnet. +du deine Anwendung horizontal skalieren willst (um mehr Instanzen auszuführen +und dadurch mehr Gesamtressourcen bereitstellen), solltest du mehrere Pods +verwenden, einen für jede Instanz. +In Kubernetes wird dies typischerweise als Replikation bezeichnet. Replizierte Pods werden normalerweise als eine Gruppe durch eine Workload-Ressource und deren {{}} erstellt @@ -109,7 +108,7 @@ virtuellen Server im Cluster befinden. Die Container können Ressourcen und Abhängigkeiten gemeinsam nutzen, miteinander kommunizieren und ferner koordinieren wann und wie sie beendet werden. -Zum Beispiel könnten Sie einen Container haben, der als Webserver für Dateien in +Zum Beispiel könntest du einen Container haben, der als Webserver für Dateien in einem gemeinsamen Volume arbeitet. Und ein separater "Sidecar" -Container aktualisiert die Daten von einer externen Datenquelle, siehe folgenden Abbildung: @@ -129,7 +128,7 @@ enthaltenen Container bereit: ## Mit Pods arbeiten -Sie werden selten einzelne Pods direkt in Kubernetes erstellen, selbst +Du wirst selten einzelne Pods direkt in Kubernetes erstellen, selbst Singleton-Pods. Das liegt daran, dass Pods als relativ kurzlebige Einweg-Einheiten konzipiert sind. Wann Ein Pod erstellt wird (entweder direkt von Ihnen oder indirekt von einem @@ -145,16 +144,16 @@ eines Pods verwechselt werden. Ein Pod ist kein Prozess, sondern eine Umgebung zur Ausführung von Containern. Ein Pod bleibt bestehen bis er gelöscht wird. {{< /note >}} -Stellen Sie beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der +Stelle beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der angegebene Name ein gültiger [DNS-Subdomain-Name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) ist. ### Pods und Controller -Mit Workload-Ressourcen können Sie mehrere Pods erstellen und verwalten. Ein +Mit Workload-Ressourcen kannst du mehrere Pods erstellen und verwalten. Ein Controller für die Ressource kümmert sich um Replikation, Roll-Out sowie -automatische Heilung im Fall von Podfehlern. Wenn beispielsweise ein Node +automatische Wiederherstellung im Fall von versagenden Pods. Wenn beispielsweise ein Node ausfällt, bemerkt ein Controller, dass die Pods auf dem Node nicht mehr laufen und plant die Ausführung eines Ersatzpods auf einem funktionierenden Node. Hier sind einige Beispiele für Workload-Ressourcen, die einen oder mehrere Pods @@ -164,22 +163,22 @@ verwalten: * {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} * {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} -### Podvorlagen +### Pod Vorlagen Controller für {{}}-Ressourcen -erstellen Pods von einer _Podvorlage_ und verwalten diese Pods für sie. +erstellen Pods von einer _Pod Vorlage_ und verwalten diese Pods für dich. -Podvorlagen sind Spezifikationen zum Erstellen von Pods und sind in +Pod Vorlagen sind Spezifikationen zum Erstellen von Pods und sind in Workload-Ressourcen enthalten wie z. B. [Deployments](/docs/concepts/workloads/controllers/deployment/), [Jobs](/docs/concepts/workloads/controllers/job/), and [DaemonSets](/docs/concepts/workloads/controllers/daemonset/). -Jeder Controller für eine Workload-Ressource verwendet die Podvorlage innerhalb -des Workload-Objektes, um Pods zu erzeugen. Die Podvorlage ist Teil des -gewünschten Zustands der Workload-Ressource, mit der Sie Ihre Anwendung -ausgeführt haben. +Jeder Controller für eine Workload-Ressource verwendet die Pod Vorlage innerhalb +des Workload-Objektes, um Pods zu erzeugen. Die Pod Vorlage ist Teil des +gewünschten Zustands der Workload-Ressource, mit der du deine Anwendung +ausgeführt hast. Das folgende Beispiel ist ein Manifest für einen einfachen Job mit einer `Vorlage`, die einen Container startet. Der Container in diesem Pod druckt @@ -192,37 +191,37 @@ metadata: name: hello spec: template: - # Dies is the Podvorlage + # Dies is the Pod Vorlage spec: containers: - name: hello image: busybox command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure - # Die Podvorlage endet hier + # Die Pod Vorlage endet hier ``` -Das Ändern der Podvorlage oder der Wechsel zu einer neuen Podvorlage hat keine -direkten Auswirkungen auf bereits existierende Pods. Wenn Sie die Podvorlage für -eine Workload-Ressource ändern, dann muss diese Ressource die Ersatz-Pods +Das Ändern der Pod Vorlage oder der Wechsel zu einer neuen Pod Vorlage hat keine +direkten Auswirkungen auf bereits existierende Pods. Wenn du die Pod Vorlage für +eine Workload-Ressource änderst, dann muss diese Ressource die Ersatz-Pods erstellen, welche die aktualisierte Vorlage verwenden. Beispielsweise stellt der StatefulSet-Controller sicher, dass für jedes -StatefulSet-Objekt die ausgeführten Pods mit der aktueller Podvorlage -übereinstimmen. Wenn Sie das StatefulSet bearbeiten und die Vorlage ändern, +StatefulSet-Objekt die ausgeführten Pods mit der aktueller Pod Vorlage +übereinstimmen. Wenn du das StatefulSet bearbeitest und die Vorlage änderst, beginnt das StatefulSet mit der Erstellung neuer Pods basierend auf der aktualisierten Vorlage. Schließlich werden alle alten Pods durch neue Pods ersetzt, und das Update ist abgeschlossen. Jede Workload-Ressource implementiert eigenen Regeln für die Umsetzung von -Änderungen der Podvorlage. Wenn Sie mehr über StatefulSet erfahren möchten, -lesen Sie die Seite +Änderungen der Pod Vorlage. Wenn du mehr über StatefulSet erfahren möchtest, +dann lese die Seite [Update-Strategien](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) im Tutorial StatefulSet Basics. Auf Nodes beobachtet oder verwaltet das {{< glossary_tooltip term_id="kubelet" text="Kubelet" >}} -nicht direkt die Details zu Podvorlagen und Updates. Diese Details sind +nicht direkt die Details zu Pod Vorlagen und Updates. Diese Details sind abstrahiert. Die Abstraktion und Trennung von Aufgaben vereinfacht die Systemsemantik und ermöglicht so das Verhalten des Clusters zu ändern ohne vorhandenen Code zu ändern. @@ -230,10 +229,10 @@ vorhandenen Code zu ändern. ## Pod Update und Austausch Wie im vorherigen Abschnitt erwähnt, erstellt der Controller neue Pods basierend -auf der aktualisierten Vorlage, wenn die Podvorlage für eine Workload-Ressource +auf der aktualisierten Vorlage, wenn die Pod Vorlage für eine Workload-Ressource geändert wird anstatt die vorhandenen Pods zu aktualisieren oder zu patchen. -Kubernetes hindert Sie nicht daran, Pods direkt zu verwalten. Es ist möglich, +Kubernetes hindert dich nicht daran, Pods direkt zu verwalten. Es ist möglich, einige Felder eines laufenden Pods zu aktualisieren. Allerdings haben Pod-Aktualisierungsvorgänge wie zum Beispiel [`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), @@ -241,8 +240,8 @@ und [`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core) einige Einschränkungen: -- Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel können - Sie nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` +- Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel kannst + du nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` ändern. Das `generation`-Feld muss eindeutig sein. Es werden nur Aktualisierungen akzeptiert, die den Wert des Feldes inkrementieren. - Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer @@ -250,7 +249,7 @@ einige Einschränkungen: - Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind `spec.containers[*].image`, `spec.initContainers[*].image`,` spec.activeDeadlineSeconds` oder - `spec.tolerations`. Für `spec.tolerations` können Sie nur neue Einträge + `spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge hinzufügen. - Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt: @@ -269,7 +268,7 @@ Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert werden, falls einer der Container neu gestartet werden muss. -Im Kapitel [Datenspeicherung](/docs/concepts/storage/) finden Sie weitere +Im Kapitel [Datenspeicherung](/docs/concepts/storage/) findest du weitere Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und Pods zur Verfügung stellt. @@ -321,7 +320,7 @@ _Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node verwaltet ohne dass sie vom {{}} überwacht werden. -. + Die meisten Pods werden von der Kontrollebene verwaltet (z. B. {{< glossary_tooltip text="Deployment" term_id="deployment" >}}). Aber für statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet @@ -342,16 +341,16 @@ sichtbar sind jedoch von dort nicht gesteuert werden können. ## {{% heading "whatsnext" %}} -* Erfahren Sie mehr über den +* Lerne den [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/). -* Erfahren Sie mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) - und wie Sie damit verschiedene Pods mit unterschiedlichen - Container-Laufzeitumgebungen konfigurieren können. -* Lesen sie mehr über +* Lerne die [RuntimeClass](/docs/concepts/containers/runtime-class/) + und wie du damit verschiedene Pods mit unterschiedlichen + Container-Laufzeitumgebungen konfigurieren kannst. +* Lese [Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). -* Lesen sie mehr über sogenannte - [Pod-Disruption-Budgets](/docs/concepts/workloads/pods/disruptions/) - und wie Sie diese verwenden können, um die Verfügbarkeit von Anwendungen bei +* Lese + [Pod-Disruption-Budget](/docs/concepts/workloads/pods/disruptions/) + und wie du es verwenden kannst, um die Verfügbarkeit von Anwendungen bei Störungen zu verwalten. Die [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) -Objektdefinition beschreibt das Objekt im Detail. @@ -362,7 +361,7 @@ Um den Hintergrund zu verstehen, warum Kubernetes eine gemeinsame Pod-API in andere Ressourcen, wie z. B. {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} oder {{< glossary_tooltip text="Deployments" term_id="deployment" >}} einbindet, -können sie Artikel zu früheren Technologien lesen, unter anderem: +kannst du Artikel zu früheren Technologien lesen, unter anderem: * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) * [Borg](https://research.google.com/pubs/pub43438.html) * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) From 29520dbf08d7171bef0d38fee19b6300176a55f2 Mon Sep 17 00:00:00 2001 From: Kobayashi Date: Wed, 17 Feb 2021 17:34:57 +0900 Subject: [PATCH 0012/1733] Copy file "docs/contribute/perticipate/_index.md" to translate --- .../ja/docs/contribute/perticipate/_index.md | 120 ++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 content/ja/docs/contribute/perticipate/_index.md diff --git a/content/ja/docs/contribute/perticipate/_index.md b/content/ja/docs/contribute/perticipate/_index.md new file mode 100644 index 0000000000..6a86326945 --- /dev/null +++ b/content/ja/docs/contribute/perticipate/_index.md @@ -0,0 +1,120 @@ +--- +title: Participating in SIG Docs +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + + + +SIG Docs is one of the +[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) +within the Kubernetes project, focused on writing, updating, and maintaining +the documentation for Kubernetes as a whole. See +[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) +for more information about the SIG. + +SIG Docs welcomes content and reviews from all contributors. Anyone can open a +pull request (PR), and anyone is welcome to file issues about content or comment +on pull requests in progress. + +You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members), +[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or +[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers). +These roles require greater access and entail certain responsibilities for +approving and committing changes. See +[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +for more information on how membership works within the Kubernetes community. + +The rest of this document outlines some unique ways these roles function within +SIG Docs, which is responsible for maintaining one of the most public-facing +aspects of Kubernetes -- the Kubernetes website and documentation. + + + +## SIG Docs chairperson + +Each SIG, including SIG Docs, selects one or more SIG members to act as +chairpersons. These are points of contact between SIG Docs and other parts of +the Kubernetes organization. They require extensive knowledge of the structure +of the Kubernetes project as a whole and how SIG Docs works within it. See +[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +for the current list of chairpersons. + +## SIG Docs teams and automation + +Automation in SIG Docs relies on two different mechanisms: +GitHub teams and OWNERS files. + +### GitHub teams + +There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub: + +- `@sig-docs-{language}-owners` are approvers and leads +- `@sig-docs-{language}-reviewers` are reviewers + +Each can be referenced with their `@name` in GitHub comments to communicate with +everyone in that group. + +Sometimes Prow and GitHub teams overlap without matching exactly. For +assignment of issues, pull requests, and to support PR approvals, the +automation uses information from `OWNERS` files. + +### OWNERS files and front-matter + +The Kubernetes project uses an automation tool called prow for automation +related to GitHub issues and pull requests. The +[Kubernetes website repository](https://github.com/kubernetes/website) uses +two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): + +- blunderbuss +- approve + +These two plugins use the +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +files in the top level of the `kubernetes/website` GitHub repository to control +how prow works within the repository. + +An OWNERS file contains a list of people who are SIG Docs reviewers and +approvers. OWNERS files can also exist in subdirectories, and can override who +can act as a reviewer or approver of files in that subdirectory and its +descendants. For more information about OWNERS files in general, see +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). + +In addition, an individual Markdown file can list reviewers and approvers in its +front-matter, either by listing individual GitHub usernames or GitHub groups. + +The combination of OWNERS files and front-matter in Markdown files determines +the advice PR owners get from automated systems about who to ask for technical +and editorial review of their PR. + +## How merging works + +When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that +the quality of our published content is high, we limit merging pull requests to +SIG Docs approvers. Here's how it works. + +- When a pull request has both the `lgtm` and `approve` labels, has no `hold` + labels, and all tests are passing, the pull request merges automatically. +- Kubernetes organization members and SIG Docs approvers can add comments to + prevent automatic merging of a given pull request (by adding a `/hold` comment + or withholding a `/lgtm` comment). +- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. +- Only SIG Docs approvers can merge a pull request + by adding an `/approve` comment. Some approvers also perform additional + specific roles, such as [PR Wrangler](/docs/contribute/participate/pr-wranglers/) or + [SIG Docs chairperson](#sig-docs-chairperson). + + + +## {{% heading "whatsnext" %}} + + +For more information about contributing to the Kubernetes documentation, see: + +- [Contributing new content](/docs/contribute/new-content/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [Documentation style guide](/docs/contribute/style/) From 99c69c1bcc887bd6774d43ea6638139742f48d9d Mon Sep 17 00:00:00 2001 From: Kobayashi Date: Thu, 18 Feb 2021 14:06:13 +0900 Subject: [PATCH 0013/1733] Translate docs/contribute/participate/ into Japanese. --- .../ja/docs/contribute/participate/_index.md | 102 +++++++++++++++ .../ja/docs/contribute/perticipate/_index.md | 120 ------------------ 2 files changed, 102 insertions(+), 120 deletions(-) create mode 100644 content/ja/docs/contribute/participate/_index.md delete mode 100644 content/ja/docs/contribute/perticipate/_index.md diff --git a/content/ja/docs/contribute/participate/_index.md b/content/ja/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..d1f39eaffa --- /dev/null +++ b/content/ja/docs/contribute/participate/_index.md @@ -0,0 +1,102 @@ +--- +title: SIG Docsへの参加 +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + + + +SIG Docsは、Kubernetesプロジェクト内の +[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)の1つであり、 +Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。 +SIGの詳細については、[SIG DocsのGithubリポジトリ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照してください。 + +SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。 +誰でもPull Request（PR）を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。 + +あなたは、[member](/docs/contribute/participate/roles-and-responsibilities/#members)や、 +[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers)、 +[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers)になることもできます。 +これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。 +Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、 +[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +をご覧ください。 + +このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている +Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。 + + + + +## SIG Docs chairperson + +SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。 +これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。 +それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。 +現在のchairpersonのリストについては、 +[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +を参照してください。 + +## SIG Docs teamsと自動化 + +SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。 + +### GitHub teams + +GitHubには、SIG Docs +[teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) +の二つのカテゴリがあります。: + +- `@sig-docs-{language}-owners`は承認者かつリードです。 +- `@sig-docs-{language}-reviewers` はレビュアーです。 + +それぞれをGitHubコメントの`@name`で参照して、そのグループの全員とコミュニケーションできます。 + +ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。 +問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。 + +### OWNERSファイルとfront-matter + +Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 +[Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website) +は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します。： + +- blunderbuss +- approve + +これらの2つのプラグインは`kubernetes.website`のGithubリポジトリのトップレベルにある +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)ファイルと、 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)ファイルを使用して、 +リポジトリ内でのplowの動作を制御します。 + +OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。 +OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。 +一般的なOWNERSファイルの詳細については、 +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)を参照してください。 + +さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。 + +OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。 + +## マージの仕組み + +Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは http://kubernetes.io に公開されます。 +公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。 + +- Pull Requestに`lgtm`ラベルと`approve`ラベルの両方があり、`hold`ラベルがなく、すべてのテストに合格すると、Pull Requestは自動的にマージされます。 +- Kubernetes organizationのメンバーとSIG Docsの承認者はコメントを追加して、特定のPull Requestが自動的にマージされないようにすることができます（`/hold`コメントを追加するか、`/lgtm`コメントを保留します）。 +- Kubernetesメンバーは誰でも、`/lgtm`コメントを追加することで`lgtm`ラベルを追加できます。 +- `/approve`コメントを追加してPull Requestをマージできるのは、SIG Docsの承認者だけです。一部の承認者は、[PR Wrangler](/docs/contribute/participate/pr-wranglers/)や[SIG Docsのchairperson](#sig-docs-chairperson)など、追加の特定の役割も実行します。 + + + +## {{% heading "whatsnext" %}} + +Kubernetesドキュメントへの貢献の詳細については、以下を参照してください。： + +- [Contributing new content](/docs/contribute/new-content/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [ドキュメントスタイルの概要](/ja/docs/contribute/style/) diff --git a/content/ja/docs/contribute/perticipate/_index.md b/content/ja/docs/contribute/perticipate/_index.md deleted file mode 100644 index 6a86326945..0000000000 --- a/content/ja/docs/contribute/perticipate/_index.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: Participating in SIG Docs -content_type: concept -weight: 60 -card: - name: contribute - weight: 60 ---- - - - -SIG Docs is one of the -[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) -within the Kubernetes project, focused on writing, updating, and maintaining -the documentation for Kubernetes as a whole. See -[SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) -for more information about the SIG. - -SIG Docs welcomes content and reviews from all contributors. Anyone can open a -pull request (PR), and anyone is welcome to file issues about content or comment -on pull requests in progress. - -You can also become a [member](/docs/contribute/participate/roles-and-responsibilities/#members), -[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers), or -[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers). -These roles require greater access and entail certain responsibilities for -approving and committing changes. See -[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) -for more information on how membership works within the Kubernetes community. - -The rest of this document outlines some unique ways these roles function within -SIG Docs, which is responsible for maintaining one of the most public-facing -aspects of Kubernetes -- the Kubernetes website and documentation. - - - -## SIG Docs chairperson - -Each SIG, including SIG Docs, selects one or more SIG members to act as -chairpersons. These are points of contact between SIG Docs and other parts of -the Kubernetes organization. They require extensive knowledge of the structure -of the Kubernetes project as a whole and how SIG Docs works within it. See -[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) -for the current list of chairpersons. - -## SIG Docs teams and automation - -Automation in SIG Docs relies on two different mechanisms: -GitHub teams and OWNERS files. - -### GitHub teams - -There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub: - -- `@sig-docs-{language}-owners` are approvers and leads -- `@sig-docs-{language}-reviewers` are reviewers - -Each can be referenced with their `@name` in GitHub comments to communicate with -everyone in that group. - -Sometimes Prow and GitHub teams overlap without matching exactly. For -assignment of issues, pull requests, and to support PR approvals, the -automation uses information from `OWNERS` files. - -### OWNERS files and front-matter - -The Kubernetes project uses an automation tool called prow for automation -related to GitHub issues and pull requests. The -[Kubernetes website repository](https://github.com/kubernetes/website) uses -two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): - -- blunderbuss -- approve - -These two plugins use the -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -files in the top level of the `kubernetes/website` GitHub repository to control -how prow works within the repository. - -An OWNERS file contains a list of people who are SIG Docs reviewers and -approvers. OWNERS files can also exist in subdirectories, and can override who -can act as a reviewer or approver of files in that subdirectory and its -descendants. For more information about OWNERS files in general, see -[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). - -In addition, an individual Markdown file can list reviewers and approvers in its -front-matter, either by listing individual GitHub usernames or GitHub groups. - -The combination of OWNERS files and front-matter in Markdown files determines -the advice PR owners get from automated systems about who to ask for technical -and editorial review of their PR. - -## How merging works - -When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that -the quality of our published content is high, we limit merging pull requests to -SIG Docs approvers. Here's how it works. - -- When a pull request has both the `lgtm` and `approve` labels, has no `hold` - labels, and all tests are passing, the pull request merges automatically. -- Kubernetes organization members and SIG Docs approvers can add comments to - prevent automatic merging of a given pull request (by adding a `/hold` comment - or withholding a `/lgtm` comment). -- Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. -- Only SIG Docs approvers can merge a pull request - by adding an `/approve` comment. Some approvers also perform additional - specific roles, such as [PR Wrangler](/docs/contribute/participate/pr-wranglers/) or - [SIG Docs chairperson](#sig-docs-chairperson). - - - -## {{% heading "whatsnext" %}} - - -For more information about contributing to the Kubernetes documentation, see: - -- [Contributing new content](/docs/contribute/new-content/overview/) -- [Reviewing content](/docs/contribute/review/reviewing-prs) -- [Documentation style guide](/docs/contribute/style/) From fd116f4187c3d3e4a9d89e667d1d59d9072c5b81 Mon Sep 17 00:00:00 2001 From: Kobayashi Date: Fri, 19 Feb 2021 14:17:57 +0900 Subject: [PATCH 0014/1733] =?UTF-8?q?Delete=20unnecessary=20"=20=E3=80=82"?= =?UTF-8?q?.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/ja/docs/contribute/participate/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/contribute/participate/_index.md b/content/ja/docs/contribute/participate/_index.md index d1f39eaffa..9e79bf0b98 100644 --- a/content/ja/docs/contribute/participate/_index.md +++ b/content/ja/docs/contribute/participate/_index.md @@ -48,7 +48,7 @@ SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なる GitHubには、SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) -の二つのカテゴリがあります。: +の二つのカテゴリがあります: - `@sig-docs-{language}-owners`は承認者かつリードです。 - `@sig-docs-{language}-reviewers` はレビュアーです。 @@ -62,7 +62,7 @@ ProwチームとGitHub teamsが完全に一致せずに重複する場合があ Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 [Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website) -は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します。： +は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します： - blunderbuss - approve @@ -95,7 +95,7 @@ Pull Requestがコンテンツの公開に使用されるブランチにマー ## {{% heading "whatsnext" %}} -Kubernetesドキュメントへの貢献の詳細については、以下を参照してください。： +Kubernetesドキュメントへの貢献の詳細については、以下を参照してください： - [Contributing new content](/docs/contribute/new-content/overview/) - [Reviewing content](/docs/contribute/review/reviewing-prs) From ce2e5f87967615723b599da334e02e6c917df4b5 Mon Sep 17 00:00:00 2001 From: Tim Allclair Date: Fri, 19 Feb 2021 12:19:07 -0800 Subject: [PATCH 0015/1733] Add PSP to the deprecation guide --- .../docs/reference/using-api/deprecation-guide.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/content/en/docs/reference/using-api/deprecation-guide.md b/content/en/docs/reference/using-api/deprecation-guide.md index ee8328cbdd..1f3d7a9b49 100755 --- a/content/en/docs/reference/using-api/deprecation-guide.md +++ b/content/en/docs/reference/using-api/deprecation-guide.md @@ -49,6 +49,13 @@ RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served * All existing persisted objects are accessible via the new API * No notable changes +#### PodSecurityPolicy {#psp-v125} + +PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. + +PodSecurityPolicy replacements are still under discussion, but current use can be migrated to +[3rd-party admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) now. + ### v1.22 The **v1.22** release will stop serving the following deprecated API versions: @@ -234,6 +241,13 @@ The **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions * Notable changes: * `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades +#### PodSecurityPolicy {#psp-v116} + +The **extensions/v1beta1** API version of PodSecurityPolicy is no longer served as of v1.16. + +* Migrate manifests and API client to use the **policy/v1beta1** API version, available since v1.10. +* Note that the **policy/v1beta1** API version of PodSecurityPolicy will be removed in v1.25. + ## What to do ### Test with deprecated APIs disabled From 57f12c366020c97c2d4e427dbaec77e841176361 Mon Sep 17 00:00:00 2001 From: Ray Wang Date: Thu, 3 Dec 2020 17:29:26 +0800 Subject: [PATCH 0016/1733] Better module checking/initializing mechanism 1. Print a message to tell if modules need to be initialized when running `make serve` or other similar targets, and stop current make procedure. 2. Provide `module-init` target to initialize all dependencies Co-authored-by: Tim Bannister --- Makefile | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 58babc3627..a05c18aea2 100644 --- a/Makefile +++ b/Makefile @@ -19,7 +19,11 @@ help: ## Show this help. @awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST) module-check: - @git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2 + @git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2 + +module-init: + @echo "Initializing submodules..." 1>&2 + @git submodule update --init --recursive --depth 1 all: build ## Build site with production settings and put deliverables in ./public From a0d509156dc4481f854bdbd319046c7f72f19dcb Mon Sep 17 00:00:00 2001 From: Michael Taufen Date: Sun, 21 Feb 2021 14:59:34 -0800 Subject: [PATCH 0017/1733] Update ServiceAccountIssuerDiscovery docs for GA --- .../command-line-tools-reference/feature-gates.md | 5 +++-- .../configure-service-account.md | 11 +++++------ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 82eaea8390..2e9db5fce0 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -155,8 +155,6 @@ different Kubernetes components. | `SCTPSupport` | `true` | Beta | 1.19 | | | `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | | `ServerSideApply` | `true` | Beta | 1.16 | | -| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 | -| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | | | `ServiceLBNodePortControl` | `false` | Alpha | 1.20 | | | `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 | | `ServiceNodeExclusion` | `true` | Beta | 1.19 | | @@ -307,6 +305,9 @@ different Kubernetes components. | `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 | | `SCTPSupport` | `true` | Beta | 1.19 | 1.19 | | `SCTPSupport` | `true` | GA | 1.20 | - | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 | +| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | 1.20 | +| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - | | `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 | | `ServiceAppProtocol` | `true` | Beta | 1.19 | | | `ServiceAppProtocol` | `true` | GA | 1.20 | - | diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index d96a5c8270..23a76f3752 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -323,11 +323,10 @@ The application is responsible for reloading the token when it rotates. Periodic ## Service Account Issuer Discovery -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -The Service Account Issuer Discovery feature is enabled by enabling the -`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates) -and then enabling the Service Account Token Projection feature as described +The Service Account Issuer Discovery feature is enabled when the Service Account +Token Projection feature is enabled, as described [above](#service-account-token-volume-projection). {{< note >}} @@ -349,8 +348,8 @@ Configuration document at `/.well-known/openid-configuration` and the associated JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration is sometimes referred to as the _discovery document_. -When enabled, the cluster is also configured with a default RBAC ClusterRole -called `system:service-account-issuer-discovery`. No role bindings are provided +Clusters include a default RBAC ClusterRole called +`system:service-account-issuer-discovery`. No role bindings are provided by default. Administrators may, for example, choose whether to bind the role to `system:authenticated` or `system:unauthenticated` depending on their security requirements and which external systems they intend to federate with. From 363545ef9673242e21eacad2c6259a0be803a33c Mon Sep 17 00:00:00 2001 From: flo-oss Date: Mon, 22 Feb 2021 21:35:48 -0800 Subject: [PATCH 0018/1733] Slightly more creative translation to make it sound less repetitive and less commanding :-) --- content/de/docs/concepts/workloads/pods/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md index e6adce49a6..956190e6c7 100644 --- a/content/de/docs/concepts/workloads/pods/_index.md +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -341,12 +341,12 @@ sichtbar sind jedoch von dort nicht gesteuert werden können. ## {{% heading "whatsnext" %}} -* Lerne den +* Verstehe den [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/). -* Lerne die [RuntimeClass](/docs/concepts/containers/runtime-class/) +* Erfahre mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) und wie du damit verschiedene Pods mit unterschiedlichen Container-Laufzeitumgebungen konfigurieren kannst. -* Lese +* Mehr zum Thema [Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). * Lese [Pod-Disruption-Budget](/docs/concepts/workloads/pods/disruptions/) From a799505a5e8c8986908dd2c6e4204106bc6d129f Mon Sep 17 00:00:00 2001 From: Ricardo Pchevuzinske Katz Date: Thu, 25 Feb 2021 14:37:40 -0300 Subject: [PATCH 0019/1733] Add netpol endport documentation before release --- .../services-networking/network-policies.md | 43 ++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 2000d838b4..2a829b3ab4 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -221,6 +221,48 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. {{< /note >}} +## Targeting a range of Ports + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +When writing a Network Policy, you can target a range of Ports instead of a single port. + +This is achiveable with the usage of the `endPort` field, as the following example: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: multi-port-egress + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Egress + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 32000 + endPort: 32768 +``` + +The above rule will allow a Pod with label `db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` if the target port is between the range 32000 and 32768. + +The following restrictions apply when using this field: +* As an alpha feature, this is disabled by default. To enable endPort field at a cluster level, you (or your cluster administrator) will need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=NetworkPolicyEndPort=true,…`. +* The `endPort` field must be equal than or greater to `port` field. +* `endPort` can only be defined if `port` is also defined. +* When using `endPort` field, the `port` field must be numeric. + +{{< note >}} +You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports endPort field in NetworkPolicies ports specification. +{{< /note >}} + ## What you can't do with network policies (at least, not yet) As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API. @@ -232,7 +274,6 @@ As of Kubernetes 1.20, the following functionality does not exist in the Network - Creation or management of "Policy requests" that are fulfilled by a third party. - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). - Advanced policy querying and reachability tooling. -- The ability to target ranges of Ports in a single policy declaration. - The ability to log network security events (for example connections that are blocked or accepted). - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). From 05e03289a96f94261339df13a8e84624f244acdb Mon Sep 17 00:00:00 2001 From: Abdullah Gharaibeh Date: Fri, 26 Feb 2021 14:52:47 -0500 Subject: [PATCH 0020/1733] ttlafterfinish to beta --- .../docs/concepts/workloads/controllers/ttlafterfinished.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md index 65527e5ce2..266e72a79f 100644 --- a/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/en/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -8,7 +8,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} The TTL controller provides a TTL (time to live) mechanism to limit the lifetime of resource objects that have finished execution. TTL controller only handles @@ -16,9 +16,9 @@ objects that have finished execution. TTL controller only handles and may be expanded to handle other resources that will finish execution, such as Pods and custom resources. -Alpha Disclaimer: this feature is currently alpha, and can be enabled with both kube-apiserver and kube-controller-manager +This feature is currently beta and enabled by default, and can be disabled via [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) -`TTLAfterFinished`. +`TTLAfterFinished` in both kube-apiserver and kube-controller-manager. From c0bb986cd6537034d523e917cfc2728aa56e6a9d Mon Sep 17 00:00:00 2001 From: Ricardo Katz Date: Fri, 26 Feb 2021 17:34:57 -0300 Subject: [PATCH 0021/1733] Add review suggestions Co-authored-by: Tim Bannister --- .../en/docs/concepts/services-networking/network-policies.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 2a829b3ab4..d5c14f9465 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -225,7 +225,7 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha {{< feature-state for_k8s_version="v1.21" state="alpha" >}} -When writing a Network Policy, you can target a range of Ports instead of a single port. +When writing a NetworkPolicy, you can target a range of ports instead of a single port. This is achiveable with the usage of the `endPort` field, as the following example: @@ -260,7 +260,8 @@ The following restrictions apply when using this field: * When using `endPort` field, the `port` field must be numeric. {{< note >}} -You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports endPort field in NetworkPolicies ports specification. +Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that +supports the `endPort` field in NetworkPolicy specifications. {{< /note >}} ## What you can't do with network policies (at least, not yet) From bc023f265cfe4829e09e74859219dd7fbd65124f Mon Sep 17 00:00:00 2001 From: Richard Li Date: Sat, 27 Feb 2021 07:03:42 -0500 Subject: [PATCH 0022/1733] add blog post on using kubectl annotate for human service discovery --- .../2021-02-27-annotating-k8s-for-humans.md | 99 +++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md new file mode 100644 index 0000000000..bfc49a431b --- /dev/null +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -0,0 +1,99 @@ +--- +layout: blog +title: 'Annotating Kubernetes Services for Humans' +date: 2021-02-27 +slug: annotating-k8s-for-humans +--- + +**Authors:** Richard Li (Ambassador Labs) + +Have you ever been asked to troubleshoot a failing Kubernetes service and struggled to find basic information about the service such as the source repository and owner? + +One of the problems as Kubernetes applications grow is the proliferation of services. As the number of services grows, developers start to specialize working with specific services. When it comes to troubleshooting, however, developers need to be able to find the source, understand the service and dependencies, and chat with the owning team for any service. + +## Human Service Discovery + +Troubleshooting always begins with information gathering. While much attention has been paid to centralizing machine data (e.g., logs, metrics), much less attention has been given to the human aspect of service discovery. Who owns a particular service? What Slack channel does the team work on? Where is the source for the service? What issues are currently known and being tracked? + +## Kubernetes Annotations + +Kubernetes annotations are designed to solve exactly this problem. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. As such, annotations can contain any type of data. This is a contrast to labels, which are designed for uses internal to Kubernetes. As such, label structure and values are [constrained](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) so they can be efficiently used by Kubernetes. + + +## Kubernetes Annotations in Action + +Here is an example. Imagine you have a Kubernetes service for quoting, called the quote service. You can do the following: + +``` +$ kubectl annotate service quote a8r.io/owner=”@sally” +``` + +In this example, we’ve just added an annotation called `a8r.io/owner` with the value of @sally. Now, we can use `kubectl describe` to get the information. + +``` +$ kubectl describe svc quote +Name: quote +Namespace: default +Labels: +Annotations: a8r.io/owner: @sally +Selector: app=quote +Type: ClusterIP +IP: 10.109.142.131 +Port: http 80/TCP +TargetPort: 8080/TCP +Endpoints: +Session Affinity: None +Events: +``` + +If you’re practicing GitOps (and you should be!) you’ll want to code these values directly into your Kubernetes manifest, e.g., + +``` +apiVersion: v1 +kind: Service +metadata: + name: quote + annotations: + a8r.io/owner: “@sally” +spec: + ports: + - name: http + port: 80 + targetPort: 8080 + selector: + app: quote +``` + +## A Convention for Annotations + +Adopting a common convention for annotations ensures consistency and understandability. Typically, you’ll want to attach the annotation to the service object, as services are the high-level resource that maps most clearly to a team’s responsibility. Namespacing your annotations is also very important. Here is one set of conventions, documented at [a8r.io](https://a8r.io), and reproduced below: + +| Annotation | Description | +| ------------------------------------------ | ------------------------------------------- | +| `a8r.io/description` | Unstructured text description of the service for humans. | +| `a8r.io/owner` | SSO username (GitHub), email address (linked to GitHub account), or unstructured owner description. | +| `a8r.io/chat` | Slack channel, or link to external chat system | +| `a8r.io/bugs` | Link to external bug tracker | +| `a8r.io/logs` | Link to external log viewer | +| `a8r.io/documentation` | Link to external project documentation | +| `a8r.io/repository` | Link to external VCS repository | +| `a8r.io/support` | Link to external support center | +| `a8r.io/runbook` | Link to external project runbook | +| `a8r.io/incidents` | Link to external incident dashboard | +| `a8r.io/uptime` | Link to external uptime dashboard | +| `a8r.io/performance` | Link to external performance dashboard | +| `a8r.io/dependencies` | Unstructured text describing the service dependencies for humans. | + + +## Visualizing Annotations: Service Catalogs + +As the number of microservices and annotations proliferate, using `kubectl describe` can get tedious. Moreover, kubectl describe requires every developer to have some direct access to the Kubernetes cluster. A [service catalog](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog) presents an internal, developer-oriented view of all services. + +Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include Backstage and Ambassador. [Backstage](https://backstage.io/) is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while [Ambassador](https://www.getambassador.io/products/service-catalog) provides a turnkey, cloud-hosted solution that can be set up quickly. + +## Annotate Your Services Now and Thank Yourself Later +Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Typically, something is on fire in production and you wished you had implemented better metrics and also specified which Slack channel the owning team lived in within your organization. + +There's enormous benefits to building an effective “[version 0](https://www.getambassador.io/learn/kubernetes-glossary/version-0/)” of any service: a “[dancing skeleton](https://containerjournal.com/topics/container-management/dancing-skeleton-apis-and-microservices/)” application with a thin slice of complete functionality that can be deployed to production with a minimal yet effective continuous delivery pipeline. + +Adding service annotations should be an essential part of your “version 0” for all of your services. Add them now, and you’ll thank yourself later. From ecd25dfefb01c707393a579087b39026ab522775 Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:09:13 -0500 Subject: [PATCH 0023/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index bfc49a431b..a1969cd9cc 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -17,7 +17,7 @@ Troubleshooting always begins with information gathering. While much attention h ## Kubernetes Annotations -Kubernetes annotations are designed to solve exactly this problem. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. As such, annotations can contain any type of data. This is a contrast to labels, which are designed for uses internal to Kubernetes. As such, label structure and values are [constrained](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) so they can be efficiently used by Kubernetes. +Kubernetes annotations are designed to solve exactly this problem. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. As such, annotations can contain any type of data. This is a contrast to labels, which are designed for uses internal to Kubernetes. As such, label structure and values are [constrained](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) so they can be efficiently used by Kubernetes. ## Kubernetes Annotations in Action From eeb8c0b45ec3972d942c32d791d8d68dbbe5c2fc Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:09:20 -0500 Subject: [PATCH 0024/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index a1969cd9cc..9a0c166421 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -87,7 +87,7 @@ Adopting a common convention for annotations ensures consistency and understanda ## Visualizing Annotations: Service Catalogs -As the number of microservices and annotations proliferate, using `kubectl describe` can get tedious. Moreover, kubectl describe requires every developer to have some direct access to the Kubernetes cluster. A [service catalog](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog) presents an internal, developer-oriented view of all services. +As the number of microservices and annotations proliferate, running `kubectl describe` can get tedious. Moreover, using `kubectl describe` requires every developer to have some direct access to the Kubernetes cluster. An [service catalog](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog), in the Ambassador meaning of that term, presents an internal, developer-oriented view of all services. Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include Backstage and Ambassador. [Backstage](https://backstage.io/) is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while [Ambassador](https://www.getambassador.io/products/service-catalog) provides a turnkey, cloud-hosted solution that can be set up quickly. From 69ee6318a5f6d293f2c9a2c3bfd2dfd371af228b Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:10:02 -0500 Subject: [PATCH 0025/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index 9a0c166421..ddf0bca364 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -92,7 +92,7 @@ As the number of microservices and annotations proliferate, running `kubectl des Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include Backstage and Ambassador. [Backstage](https://backstage.io/) is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while [Ambassador](https://www.getambassador.io/products/service-catalog) provides a turnkey, cloud-hosted solution that can be set up quickly. ## Annotate Your Services Now and Thank Yourself Later -Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Typically, something is on fire in production and you wished you had implemented better metrics and also specified which Slack channel the owning team lived in within your organization. +Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Don't wait until something is on fire in production to start wishing you had implemented better metrics and also documented how to get in touch with the part of your organization that looks after it. There's enormous benefits to building an effective “[version 0](https://www.getambassador.io/learn/kubernetes-glossary/version-0/)” of any service: a “[dancing skeleton](https://containerjournal.com/topics/container-management/dancing-skeleton-apis-and-microservices/)” application with a thin slice of complete functionality that can be deployed to production with a minimal yet effective continuous delivery pipeline. From dc86d666482105fc0edfe4b392c7ab0d5a54ad2a Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:11:11 -0500 Subject: [PATCH 0026/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index ddf0bca364..994601a9f3 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -85,7 +85,7 @@ Adopting a common convention for annotations ensures consistency and understanda | `a8r.io/dependencies` | Unstructured text describing the service dependencies for humans. | -## Visualizing Annotations: Service Catalogs +## Visualizing annotations: service catalogs As the number of microservices and annotations proliferate, running `kubectl describe` can get tedious. Moreover, using `kubectl describe` requires every developer to have some direct access to the Kubernetes cluster. An [service catalog](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog), in the Ambassador meaning of that term, presents an internal, developer-oriented view of all services. From 3188c43241b6be5484b65dd351417ca36b66ef65 Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:11:17 -0500 Subject: [PATCH 0027/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index 994601a9f3..1c05fe2410 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -91,7 +91,7 @@ As the number of microservices and annotations proliferate, running `kubectl des Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include Backstage and Ambassador. [Backstage](https://backstage.io/) is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while [Ambassador](https://www.getambassador.io/products/service-catalog) provides a turnkey, cloud-hosted solution that can be set up quickly. -## Annotate Your Services Now and Thank Yourself Later +## Annotate your services now and thank yourself later Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Don't wait until something is on fire in production to start wishing you had implemented better metrics and also documented how to get in touch with the part of your organization that looks after it. There's enormous benefits to building an effective “[version 0](https://www.getambassador.io/learn/kubernetes-glossary/version-0/)” of any service: a “[dancing skeleton](https://containerjournal.com/topics/container-management/dancing-skeleton-apis-and-microservices/)” application with a thin slice of complete functionality that can be deployed to production with a minimal yet effective continuous delivery pipeline. From a381d88fe26590491b5e81652afa18b7651caf9f Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:11:26 -0500 Subject: [PATCH 0028/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index 1c05fe2410..87af6e8863 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -11,7 +11,7 @@ Have you ever been asked to troubleshoot a failing Kubernetes service and strugg One of the problems as Kubernetes applications grow is the proliferation of services. As the number of services grows, developers start to specialize working with specific services. When it comes to troubleshooting, however, developers need to be able to find the source, understand the service and dependencies, and chat with the owning team for any service. -## Human Service Discovery +## Human service discovery Troubleshooting always begins with information gathering. While much attention has been paid to centralizing machine data (e.g., logs, metrics), much less attention has been given to the human aspect of service discovery. Who owns a particular service? What Slack channel does the team work on? Where is the source for the service? What issues are currently known and being tracked? From 5b3eedc8c2ccbcb149e535aff6a2ce6d1fb47d37 Mon Sep 17 00:00:00 2001 From: Richard Li Date: Mon, 1 Mar 2021 08:49:44 -0500 Subject: [PATCH 0029/1733] clarify difference with k8s service catalog Signed-off-by: Richard Li --- .../blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index 87af6e8863..d2c4223713 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -5,7 +5,7 @@ date: 2021-02-27 slug: annotating-k8s-for-humans --- -**Authors:** Richard Li (Ambassador Labs) +**Author:** Richard Li, Ambassador Labs Have you ever been asked to troubleshoot a failing Kubernetes service and struggled to find basic information about the service such as the source repository and owner? @@ -15,7 +15,7 @@ One of the problems as Kubernetes applications grow is the proliferation of serv Troubleshooting always begins with information gathering. While much attention has been paid to centralizing machine data (e.g., logs, metrics), much less attention has been given to the human aspect of service discovery. Who owns a particular service? What Slack channel does the team work on? Where is the source for the service? What issues are currently known and being tracked? -## Kubernetes Annotations +## Kubernetes annotations Kubernetes annotations are designed to solve exactly this problem. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. As such, annotations can contain any type of data. This is a contrast to labels, which are designed for uses internal to Kubernetes. As such, label structure and values are [constrained](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) so they can be efficiently used by Kubernetes. @@ -87,9 +87,9 @@ Adopting a common convention for annotations ensures consistency and understanda ## Visualizing annotations: service catalogs -As the number of microservices and annotations proliferate, running `kubectl describe` can get tedious. Moreover, using `kubectl describe` requires every developer to have some direct access to the Kubernetes cluster. An [service catalog](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog), in the Ambassador meaning of that term, presents an internal, developer-oriented view of all services. +As the number of microservices and annotations proliferate, running `kubectl describe` can get tedious. Moreover, using `kubectl describe` requires every developer to have some direct access to the Kubernetes cluster. Over the past few years, [service catalogs](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog) have gained greater visibility in the Kubernetes ecosystem. Popularized by tools such as [Shopify's ServicesDB](https://shopify.engineering/scaling-mobile-development-by-treating-apps-as-services) and [Spotify's System Z](https://dzone.com/articles/modeling-microservices-at-spotify-with-petter-mari), service catalogs are internally-facing developer portals that present critical information about microservices. Note that these service catalogs should not be confused with the [Kubernetes Service Catalog project](https://svc-cat.io/). Built on the Open Service Broker API, the Kubernetes Service Catalog enables Kubernetes operators to plug in different services (e.g., databases) to their cluster. -Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include Backstage and Ambassador. [Backstage](https://backstage.io/) is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while [Ambassador](https://www.getambassador.io/products/service-catalog) provides a turnkey, cloud-hosted solution that can be set up quickly. +Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include [Backstage]((https://backstage.io/) and [Ambassador Service Catalog](https://www.getambassador.io/products/service-catalog). Backstage is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while Ambassador Service Catalog provides a turnkey, cloud-hosted solution that can be set up quickly. ## Annotate your services now and thank yourself later Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Don't wait until something is on fire in production to start wishing you had implemented better metrics and also documented how to get in touch with the part of your organization that looks after it. From 77f868eb1390f0f58d193037134a41ccf99b9515 Mon Sep 17 00:00:00 2001 From: Ricardo Pchevuzinske Katz Date: Mon, 1 Mar 2021 17:43:31 -0300 Subject: [PATCH 0030/1733] Add featuregate documentation and correct some doc suggestion --- .../en/docs/concepts/services-networking/network-policies.md | 2 +- .../reference/command-line-tools-reference/feature-gates.md | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index d5c14f9465..349fe84fbb 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -257,7 +257,7 @@ The following restrictions apply when using this field: * As an alpha feature, this is disabled by default. To enable endPort field at a cluster level, you (or your cluster administrator) will need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=NetworkPolicyEndPort=true,…`. * The `endPort` field must be equal than or greater to `port` field. * `endPort` can only be defined if `port` is also defined. -* When using `endPort` field, the `port` field must be numeric. +* Both ports must be numeric. {{< note >}} Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 033b38a112..df65121aff 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -135,6 +135,7 @@ different Kubernetes components. | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | | | `MixedProtocolLBService` | `false` | Alpha | 1.20 | | +| `NetworkPolicyEndPort` | `false` | Alpha | 1.21 | | | `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 | | `NodeDisruptionExclusion` | `true` | Beta | 1.19 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 | @@ -657,6 +658,7 @@ Each feature gate is designed for enabling/disabling a specific feature: the volume mounter. - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods. For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation). +- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, allowing the selection of a port range instead of a single port. - `NodeDisruptionExclusion`: Enable use of the Node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures. - `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal. From a3986feedd5056efe5d58914346080c15023871d Mon Sep 17 00:00:00 2001 From: Kornel Bicskei <48224080+kornelbicskei@users.noreply.github.com> Date: Mon, 1 Mar 2021 21:05:35 -0800 Subject: [PATCH 0031/1733] Update documentation for AWS ELB Add more details on the mechanics of security group annotations as incorrect use could potentially cause an outage. --- .../en/docs/concepts/services-networking/service.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index b7a7edcd38..55d156060f 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -906,11 +906,18 @@ There are other annotations to manage Classic Elastic Load Balancers that are de # value. Defaults to 5, must be between 2 and 60 service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" - # A list of existing security groups to be added to ELB created. Unlike the annotation - # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB. + # A list of existing security groups to be configured on the ELB created. Unlike the annotation + # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation + # of a uniquely generated security group for this ELB. + # The first security group ID on this list is used as a source to permit incoming traffic to target worker nodes (service traffic and health checks). + # If multiple ELBs are configured with the same security group ID, only a single permit line will be added to the worker node security groups, that means if you delete any + # of those ELBs it will remove the single permit line and block access for all ELBs that shared the same security group ID. + # This can cause a cross-service outage if not used properly service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" - # A list of additional security groups to be added to the ELB + # A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB + # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks). + # Security groups defined here can be shared between services. service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # A comma separated list of key-value pairs which are used From 2300a732101af99e171b669d5d8bde07b5c28465 Mon Sep 17 00:00:00 2001 From: Richard Li Date: Tue, 2 Mar 2021 09:01:39 -0500 Subject: [PATCH 0032/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index d2c4223713..922debf381 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -25,7 +25,7 @@ Kubernetes annotations are designed to solve exactly this problem. Oft-overlooke Here is an example. Imagine you have a Kubernetes service for quoting, called the quote service. You can do the following: ``` -$ kubectl annotate service quote a8r.io/owner=”@sally” +kubectl annotate service quote a8r.io/owner=”@sally” ``` In this example, we’ve just added an annotation called `a8r.io/owner` with the value of @sally. Now, we can use `kubectl describe` to get the information. From 48bd9a6a441db79c63a2080f6af7c50a2f15026e Mon Sep 17 00:00:00 2001 From: Richard Li Date: Tue, 2 Mar 2021 09:10:11 -0500 Subject: [PATCH 0033/1733] a few more fixes --- .../2021-02-27-annotating-k8s-for-humans.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index d2c4223713..81b14038e5 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -31,7 +31,6 @@ $ kubectl annotate service quote a8r.io/owner=”@sally” In this example, we’ve just added an annotation called `a8r.io/owner` with the value of @sally. Now, we can use `kubectl describe` to get the information. ``` -$ kubectl describe svc quote Name: quote Namespace: default Labels: @@ -48,7 +47,7 @@ Events: If you’re practicing GitOps (and you should be!) you’ll want to code these values directly into your Kubernetes manifest, e.g., -``` +```yaml apiVersion: v1 kind: Service metadata: @@ -68,20 +67,21 @@ spec: Adopting a common convention for annotations ensures consistency and understandability. Typically, you’ll want to attach the annotation to the service object, as services are the high-level resource that maps most clearly to a team’s responsibility. Namespacing your annotations is also very important. Here is one set of conventions, documented at [a8r.io](https://a8r.io), and reproduced below: +{{< table caption="Annotation convention for human-readable services">}} | Annotation | Description | | ------------------------------------------ | ------------------------------------------- | | `a8r.io/description` | Unstructured text description of the service for humans. | | `a8r.io/owner` | SSO username (GitHub), email address (linked to GitHub account), or unstructured owner description. | -| `a8r.io/chat` | Slack channel, or link to external chat system | -| `a8r.io/bugs` | Link to external bug tracker | -| `a8r.io/logs` | Link to external log viewer | -| `a8r.io/documentation` | Link to external project documentation | -| `a8r.io/repository` | Link to external VCS repository | -| `a8r.io/support` | Link to external support center | -| `a8r.io/runbook` | Link to external project runbook | -| `a8r.io/incidents` | Link to external incident dashboard | -| `a8r.io/uptime` | Link to external uptime dashboard | -| `a8r.io/performance` | Link to external performance dashboard | +| `a8r.io/chat` | Slack channel, or link to external chat system. | +| `a8r.io/bugs` | Link to external bug tracker. | +| `a8r.io/logs` | Link to external log viewer. | +| `a8r.io/documentation` | Link to external project documentation. | +| `a8r.io/repository` | Link to external VCS repository. | +| `a8r.io/support` | Link to external support center. | +| `a8r.io/runbook` | Link to external project runbook. | +| `a8r.io/incidents` | Link to external incident dashboard. | +| `a8r.io/uptime` | Link to external uptime dashboard. | +| `a8r.io/performance` | Link to external performance dashboard. | | `a8r.io/dependencies` | Unstructured text describing the service dependencies for humans. | From 0d3e8f4a71e4202f68b69937c9427fff2ee54095 Mon Sep 17 00:00:00 2001 From: andyzhangx Date: Wed, 3 Mar 2021 13:32:00 +0000 Subject: [PATCH 0034/1733] Update Azure file feature gates for 1.21 beta --- content/en/docs/concepts/storage/volumes.md | 4 ++-- .../reference/command-line-tools-reference/feature-gates.md | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 8d84a519c0..d7eb7a1679 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -152,14 +152,14 @@ For more details, see the [`azureFile` volume plugin](https://github.com/kuberne #### azureFile CSI migration -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} The `CSIMigration` feature for `azureFile`, when enabled, redirects all plugin operations from the existing in-tree plugin to the `file.csi.azure.com` Container Storage Interface (CSI) Driver. In order to use this feature, the [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile` -alpha features must be enabled. +features must be enabled. ### cephfs diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 2e9db5fce0..f49861bd79 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -74,7 +74,8 @@ different Kubernetes components. | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 | | `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | | | `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | | -| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | | +| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | 1.19 | +| `CSIMigrationAzureFile` | `false` | Beta | 1.21 | | | `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | | | `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 | | `CSIMigrationGCE` | `false` | Beta | 1.17 | | From 3e7055c27fdcb237111e0272823fcdf5a1ff99f9 Mon Sep 17 00:00:00 2001 From: Bridget Kromhout Date: Wed, 3 Mar 2021 17:52:58 -0600 Subject: [PATCH 0035/1733] Docs update for enhancement 563, release 1.21. Signed-off-by: Bridget Kromhout --- .../concepts/services-networking/dual-stack.md | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 20cbcb5f33..5e7c3a757c 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -45,34 +45,30 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A network plugin that supports dual-stack (such as Kubenet or Calico) -## Enable IPv4/IPv6 dual-stack +## Configure IPv4/IPv6 dual-stack -To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the relevant components of your cluster, and set dual-stack cluster network assignments: +To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments: * kube-apiserver: - * `--feature-gates="IPv6DualStack=true"` * `--service-cluster-ip-range=,` * kube-controller-manager: - * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=,` * `--service-cluster-ip-range=,` * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6 - * kubelet: - * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--cluster-cidr=,` - * `--feature-gates="IPv6DualStack=true"` {{< note >}} An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own address range) An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) +Starting in 1.21, IPv4/IPv6 dual-stack defaults to true. Disable if necessary on kube-apiserver, kube-controller-manager, kubelet, and kube-proxy with `--feature-gates="IPv6DualStack=false"`. {{< /note >}} ## Services -If your cluster has dual-stack enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. +You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver). @@ -81,11 +77,9 @@ set the `.spec.ipFamilyPolicy` field to one of the following values: * `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range. * `PreferDualStack`: - * Only used if the cluster has dual-stack enabled. Allocates IPv4 and IPv6 cluster IPs for the Service - * If the cluster does not have dual-stack enabled, this setting follows the same behavior as `SingleStack`. + * Allocates IPv4 and IPv6 cluster IPs for the Service. (If the cluster has `--feature-gates="IPv6DualStack=false"`, this setting follows the same behavior as `SingleStack`.) * `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges. * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array. - * The cluster must have dual-stack networking configured. If you would like to define which IP family to use for single stack or define the order of IP families for dual-stack, you can choose the address families by setting an optional field, `.spec.ipFamilies`, on the Service. @@ -126,7 +120,7 @@ These examples demonstrate the behavior of various dual-stack Service configurat #### Dual-stack defaults on existing Services -These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. +These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 will enable dual-stack unless `--feature-gates="IPv6DualStack=false"` is set.) 1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`. From d8aa7224dda564c41ef3a758f76ff7d681af6626 Mon Sep 17 00:00:00 2001 From: Bridget Kromhout Date: Wed, 3 Mar 2021 21:14:07 -0600 Subject: [PATCH 0036/1733] Update content/en/docs/concepts/services-networking/dual-stack.md Clarifying how to disable the dual-stack feature when necessary. Co-authored-by: Qiming Teng --- content/en/docs/concepts/services-networking/dual-stack.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 5e7c3a757c..86abdf7c1d 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -63,7 +63,9 @@ An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own ad An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) -Starting in 1.21, IPv4/IPv6 dual-stack defaults to true. Disable if necessary on kube-apiserver, kube-controller-manager, kubelet, and kube-proxy with `--feature-gates="IPv6DualStack=false"`. +Starting in 1.21, IPv4/IPv6 dual-stack defaults to true. +You can disable it when necessary by specifying `--feature-gates="IPv6DualStack=false"` +on the kube-apiserver, kube-controller-manager, kubelet, and kube-proxy command line. {{< /note >}} ## Services From 31777fa6b5d5a7def51707e29ae7874a5242bf59 Mon Sep 17 00:00:00 2001 From: Bridget Kromhout Date: Wed, 3 Mar 2021 21:28:15 -0600 Subject: [PATCH 0037/1733] Update to indicate dual-stack move to beta in 1.21 Signed-off-by: Bridget Kromhout --- content/en/docs/concepts/services-networking/dual-stack.md | 2 +- .../reference/command-line-tools-reference/feature-gates.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 86abdf7c1d..9bdc756b35 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -16,7 +16,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 2e9db5fce0..835fb58d76 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -123,7 +123,7 @@ different Kubernetes components. | `HPAScaleToZero` | `false` | Alpha | 1.16 | | | `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 | | `HugePageStorageMediumSize` | `true` | Beta | 1.19 | | -| `IPv6DualStack` | `false` | Alpha | 1.15 | | +| `IPv6DualStack` | `true` | Beta | 1.21 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | | | `KubeletPodResources` | `true` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | From f5aaf40e889404ba3d88c5c518b58714cd51432c Mon Sep 17 00:00:00 2001 From: Patrick Ohly Date: Tue, 2 Mar 2021 13:47:27 +0100 Subject: [PATCH 0038/1733] storage capacity: beta After the promotion to beta in 1.21, enabling the feature is easier and mostly just depends on the CSI driver deployment. --- .../docs/concepts/storage/storage-capacity.md | 33 +++---------------- .../feature-gates.md | 3 +- 2 files changed, 7 insertions(+), 29 deletions(-) diff --git a/content/en/docs/concepts/storage/storage-capacity.md b/content/en/docs/concepts/storage/storage-capacity.md index d5993d4f59..13ae8ab722 100644 --- a/content/en/docs/concepts/storage/storage-capacity.md +++ b/content/en/docs/concepts/storage/storage-capacity.md @@ -17,6 +17,7 @@ which a pod runs: network-attached storage might not be accessible by all nodes, or storage is local to a node to begin with. {{< feature-state for_k8s_version="v1.19" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} This page describes how Kubernetes keeps track of storage capacity and how the scheduler uses that information to schedule Pods onto nodes @@ -103,34 +104,10 @@ to handle this automatically. ## Enabling storage capacity tracking -Storage capacity tracking is an *alpha feature* and only enabled when -the `CSIStorageCapacity` [feature -gate](/docs/reference/command-line-tools-reference/feature-gates/) and -the `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}} are enabled. For details on -that, see the `--feature-gates` and `--runtime-config` [kube-apiserver -parameters](/docs/reference/command-line-tools-reference/kube-apiserver/). - -A quick check -whether a Kubernetes cluster supports the feature is to list -CSIStorageCapacity objects with: -```shell -kubectl get csistoragecapacities --all-namespaces -``` - -If your cluster supports CSIStorageCapacity, the response is either a list of CSIStorageCapacity objects or: -``` -No resources found -``` - -If not supported, this error is printed instead: -``` -error: the server doesn't have a resource type "csistoragecapacities" -``` - -In addition to enabling the feature in the cluster, a CSI -driver also has to -support it. Please refer to the driver's documentation for -details. +Storage capacity tracking is a beta feature and enabled by default in +a Kubernetes cluster since Kubernetes 1.21. In addition to having the +feature enabled in the cluster, a CSI driver also has to support +it. Please refer to the driver's documentation for details. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 2e9db5fce0..91062f3895 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -85,7 +85,8 @@ different Kubernetes components. | `CSIMigrationvSphere` | `false` | Beta | 1.19 | | | `CSIMigrationvSphereComplete` | `false` | Beta | 1.19 | | | `CSIServiceAccountToken` | `false` | Alpha | 1.20 | | -| `CSIStorageCapacity` | `false` | Alpha | 1.19 | | +| `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 | +| `CSIStorageCapacity` | `true` | Beta | 1.21 | | | `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | 1.19 | | `CSIVolumeFSGroupPolicy` | `true` | Beta | 1.20 | | | `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | 1.19 | From bb9f8ebd77ed329fbf0c64517d60b24326dc8d44 Mon Sep 17 00:00:00 2001 From: Bridget Kromhout Date: Thu, 4 Mar 2021 08:02:59 -0600 Subject: [PATCH 0039/1733] Restoring alpha details with end date Signed-off-by: Bridget Kromhout --- .../docs/reference/command-line-tools-reference/feature-gates.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 835fb58d76..65a37a8a3f 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -123,6 +123,7 @@ different Kubernetes components. | `HPAScaleToZero` | `false` | Alpha | 1.16 | | | `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 | | `HugePageStorageMediumSize` | `true` | Beta | 1.19 | | +| `IPv6DualStack` | `false` | Alpha | 1.15 | 1.20 | | `IPv6DualStack` | `true` | Beta | 1.21 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | | | `KubeletPodResources` | `true` | Alpha | 1.13 | 1.14 | From 21b1e83147332372935e606adba9c6bc5bec5cdd Mon Sep 17 00:00:00 2001 From: Joe Marty Date: Thu, 4 Mar 2021 09:54:52 -0600 Subject: [PATCH 0040/1733] Clarify sources of voluntary disruptions See issue #22391 --- content/en/docs/concepts/workloads/pods/disruptions.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index d0a8bbf5a9..04c35e0322 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -80,12 +80,14 @@ Here are some ways to mitigate involuntary disruptions: [multi-zone cluster](/docs/setup/multiple-zones).) The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are -no voluntary disruptions at all. However, your cluster administrator or hosting provider +no automated voluntary disruptions (only user-triggered ones). However, your cluster administrator or hosting provider may run some additional services which cause voluntary disruptions. For example, rolling out node software updates can cause voluntary disruptions. Also, some implementations of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes. Your cluster administrator or hosting provider should have documented what level of voluntary -disruptions, if any, to expect. +disruptions, if any, to expect. Certain configuration options, such as +[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) +in your pod spec can also cause voluntary (and involuntary) disruptions. ## Pod disruption budgets From 5829a5d9584640b727b9420967a0189c6862e5b3 Mon Sep 17 00:00:00 2001 From: Richard Li Date: Thu, 4 Mar 2021 14:48:45 -0500 Subject: [PATCH 0041/1733] Update content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md Co-authored-by: Kaitlyn Barnard --- content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md index a9a65c9dae..b81c13a7f0 100644 --- a/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md +++ b/content/en/blog/_posts/2021-02-27-annotating-k8s-for-humans.md @@ -89,7 +89,7 @@ Adopting a common convention for annotations ensures consistency and understanda As the number of microservices and annotations proliferate, running `kubectl describe` can get tedious. Moreover, using `kubectl describe` requires every developer to have some direct access to the Kubernetes cluster. Over the past few years, [service catalogs](https://www.getambassador.io/learn/kubernetes-glossary/service-catalog) have gained greater visibility in the Kubernetes ecosystem. Popularized by tools such as [Shopify's ServicesDB](https://shopify.engineering/scaling-mobile-development-by-treating-apps-as-services) and [Spotify's System Z](https://dzone.com/articles/modeling-microservices-at-spotify-with-petter-mari), service catalogs are internally-facing developer portals that present critical information about microservices. Note that these service catalogs should not be confused with the [Kubernetes Service Catalog project](https://svc-cat.io/). Built on the Open Service Broker API, the Kubernetes Service Catalog enables Kubernetes operators to plug in different services (e.g., databases) to their cluster. -Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include [Backstage]((https://backstage.io/) and [Ambassador Service Catalog](https://www.getambassador.io/products/service-catalog). Backstage is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while Ambassador Service Catalog provides a turnkey, cloud-hosted solution that can be set up quickly. +Historically, service catalogs have not been a key piece of infrastructure, as applications consisted of a single monolith. Today, with distributed development and microservices the norm, service catalogs are increasingly being adopted as a best practice. Some popular options today include [Backstage](https://backstage.io/) and [Ambassador Service Catalog](https://www.getambassador.io/products/service-catalog). Backstage is a highly flexible project ideal for organizations that wish to customize every aspect of their service catalog, while Ambassador Service Catalog provides a turnkey, cloud-hosted solution that can be set up quickly. ## Annotate your services now and thank yourself later Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Don't wait until something is on fire in production to start wishing you had implemented better metrics and also documented how to get in touch with the part of your organization that looks after it. From 235509450a5e88d83a69b789ecce434548729e9d Mon Sep 17 00:00:00 2001 From: "Lubomir I. Ivanov" Date: Tue, 2 Mar 2021 00:34:50 +0200 Subject: [PATCH 0042/1733] kubeadm: add a new page - Add the new page "Configuring a cgroup driver" The page includes details on how to configure the cgroup driver using kubeadm. It also includes a migration guide for users to move to the "systemd" driver. - Link to the new page from install-kubeadm.md and container-runtimes.md --- .../container-runtimes.md | 7 +- .../tools/kubeadm/install-kubeadm.md | 34 ++--- .../kubeadm/configure-cgroup-driver.md | 127 ++++++++++++++++++ 3 files changed, 142 insertions(+), 26 deletions(-) create mode 100644 content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 5aa4ac894e..3f022d191f 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -48,7 +48,7 @@ Changing the settings such that your container runtime and kubelet use `systemd` stabilized the system. To configure this for Docker, set `native.cgroupdriver=systemd`. {{< caution >}} -Changing the cgroup driver of a Node that has joined a cluster is strongly *not* recommended. +Changing the cgroup driver of a Node that has joined a cluster is a sensitive operation. If the kubelet has created Pods using the semantics of one cgroup driver, changing the container runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox for such existing Pods. Restarting the kubelet may not solve such errors. @@ -57,6 +57,11 @@ If you have automation that makes it feasible, replace the node with another usi configuration, or reinstall it using automation. {{< /caution >}} +### Migrating to the `systemd` driver in kubeadm managed clusters + +Follow this [Migration guide](/tasks/administer-cluster/kubeadm/configure-cgroup-driver) +if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. + ## Container runtimes {{% thirdparty-content %}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 394820324d..74d6a79dca 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -233,7 +233,7 @@ sudo mkdir -p /opt/cni/bin curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz ``` -Define the directory to download command files +Define the directory to download command files {{< note >}} The `DOWNLOAD_DIR` variable must be set to a writable directory. @@ -284,33 +284,17 @@ See the [Kubeadm Troubleshooting guide](/docs/setup/production-environment/tools The kubelet is now restarting every few seconds, as it waits in a crashloop for kubeadm to tell it what to do. -## Configure cgroup driver used by kubelet on control-plane node +## Configuring a cgroup driver -When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet -and set it in the `/var/lib/kubelet/config.yaml` file during runtime. +Both the container runtime and the kubelet have a property called +["cgroup driver"](/docs/setup/production-environment/container-runtimes/), which is important +for the management of cgroups on Linux machines. -If you are using a different CRI, you must pass your `cgroupDriver` value to `kubeadm init`, like so: - -```yaml -apiVersion: kubelet.config.k8s.io/v1beta1 -kind: KubeletConfiguration -cgroupDriver: -``` - -For further details, please read [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). - -Please mind, that you **only** have to do that if the cgroup driver of your CRI -is not `cgroupfs`, because that is the default value in the kubelet already. - -{{< note >}} -Since `--cgroup-driver` flag has been deprecated by the kubelet, if you have that in `/var/lib/kubelet/kubeadm-flags.env` -or `/etc/default/kubelet`(`/etc/sysconfig/kubelet` for RPMs), please remove it and use the KubeletConfiguration instead -(stored in `/var/lib/kubelet/config.yaml` by default). -{{< /note >}} - -The automatic detection of cgroup driver for other container runtimes -like CRI-O and containerd is work in progress. +{{< warning >}} +Matching the container runtime and kubelet cgroup drivers is required or otherwise the kubelet process will fail. +{{< warning >}} +See [Configuring a cgroup driver](/tasks/administer-cluster/kubeadm/configure-cgroup-driver) for more details. ## Troubleshooting diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md new file mode 100644 index 0000000000..02fdc958fa --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -0,0 +1,127 @@ +--- +title: Configuring a cgroup driver +content_type: task +weight: 10 +--- + + + +This page explains how to configure the kubelet cgroup driver to match the container +runtime cgroup driver for kubeadm clusters. + +## {{% heading "prerequisites" %}} + +You should be familiar with the Kubernetes +[container runtime requirements](/docs/setup/production-environment/container-runtimes). + + + +## Configuring the container runtime cgroup driver + +The [Container runtimes](/docs/setup/production-environment/container-runtimes) page +explains that the `systemd` driver is recommended for kubeadm based setups instead +of the `cgroupfs` driver, because kubeadm manages the kubelet as a systemd service. + +The page also provides details on how to setup a number of different container runtimes with the +`systemd` driver by default. + +## Configuring the kubelet cgroup driver + +kubeadm allows you to pass a `KubeletConfiguration` structure during `kubeadm init`. +This `KubeletConfiguration` can include the `cgroupDriver` field which controls the cgroup +driver of the kubelet. + +{{< note >}} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +If the user is not setting the `cgroupDriver` field under `KubeletConfiguration`, +`kubeadm init` will default it to `systemd`. +{{< /note >}} + +A minimal example of configuring the field explicitly: + +```yaml +# kubeadm-config.yaml +kind: ClusterConfiguration +apiVersion: kubeadm.k8s.io/v1beta2 +kubernetesVersion: v1.21 +--- +kind: KubeletConfiguration +apiVersion: kubelet.config.k8s.io/v1beta1 +cgroupDriver: systemd +``` + +Such a configuration file can then be passed to the kubeadm command: + +```shell +kubeadm init --config kubeadm-config.yaml +``` + +{{< note >}} +Kubeadm uses the same `KubeletConfiguration` for all nodes in the cluster. +The `KubeletConfiguration` is stored in a [ConfigMap](docs/concepts/configuration/configmap) +object under the `kube-system` namespace. + +Executing the sub commands `init`, `join` and `upgrade` would result in kubeadm +writing the `KubeletConfiguration` as a file under `/var/lib/kubelet/config.yaml` +and passing it to the local node kubelet. +{{< /note >}} + +## Using the `cgroupfs` driver + +As this guide explains using the `cgroupfs` driver with kubeadm is not recommended. + +To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the +`KubeletConfiguration` cgroup driver on existing setups, you must be explicit +about its value. This applies to a case where you do not wish future versions +of kubeadm to apply the `systemd` driver by default. + +See the below section on "Modify the kubelet ConfigMap" for details on +how to be explicit about the value. + +If you wish to configure a container runtime to use the `cgroupfs` driver, +you must refer to the documentation of the container runtime of your choice. + +## Migrating to the `systemd` driver + +To change the cgroup driver of an existing kubeadm cluster to `systemd` in-place, +a similar procedure to a kubelet upgrade is required. This must include both +steps outlined below. + +{{< note >}} +Alternatively, it is possible to replace the old nodes in the cluster with new ones +that use the `systemd` driver. This requires executing only the first step below +before joining the new nodes and ensuring the workloads can safely move to the new +nodes before deleting the old nodes. +{{< /note >}} + +### Modify the kubelet ConfigMap + +- Find the kubelet ConfigMap name using `kubectl get cm -n kube-system | grep kubelet-config`. +- Call `kubectl edit cm kubelet-config-x.yy -n kube-system` (replace `x.yy` with +the Kubernetes version). +- Either modify the existing `cgroupDriver` value or add a new field that looks like this: + + ```yaml + cgroupDriver: systemd + ``` + This field must be present under the `kubelet:` section of the ConfigMap. + +### Update the cgroup driver on all nodes + +For each node in the cluster: + +- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node) using `kubectl drain --ignore-daemonsets` +- Stop the kubelet using `systemctl stop kubelet` +- Stop the container runtime +- Modify the container runtime cgroup driver to `systemd` +- Set `cgroupDriver: systemd` in `/var/lib/kubelet/config.yaml` +- Start the container runtime +- Start the kubelet using `systemctl start kubelet` +- [Uncordon the node](/docs/tasks/administer-cluster/safely-drain-node) using `kubectl uncordon ` + +Execute these steps on nodes one at a time to ensure workloads +have sufficient time to schedule on different nodes. + +Once the process is complete ensure that all nodes and workloads are healthy. From 7d5cd3207028a2dfebc37577aaa4952123ded825 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 4 Mar 2021 23:01:53 +0000 Subject: [PATCH 0043/1733] Tidy documentation on NetworkPolicy endPort field --- .../docs/concepts/services-networking/network-policies.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 349fe84fbb..32421a0beb 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -227,7 +227,7 @@ You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin tha When writing a NetworkPolicy, you can target a range of ports instead of a single port. -This is achiveable with the usage of the `endPort` field, as the following example: +This is achievable with the usage of the `endPort` field, as the following example: ```yaml apiVersion: networking.k8s.io/v1 @@ -251,11 +251,11 @@ spec: endPort: 32768 ``` -The above rule will allow a Pod with label `db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` if the target port is between the range 32000 and 32768. +The above rule allows any Pod with label `db` on the namespace `default` to communicate with any IP within the range `10.0.0.0/24` over TCP, provided that the target port is between the range 32000 and 32768. The following restrictions apply when using this field: -* As an alpha feature, this is disabled by default. To enable endPort field at a cluster level, you (or your cluster administrator) will need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=NetworkPolicyEndPort=true,…`. -* The `endPort` field must be equal than or greater to `port` field. +* As an alpha feature, this is disabled by default. To enable the `endPort` field at a cluster level, you (or your cluster administrator) need to enable the `NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=NetworkPolicyEndPort=true,…`. +* The `endPort` field must be equal than or greater to the `port` field. * `endPort` can only be defined if `port` is also defined. * Both ports must be numeric. From 99e46a58b4c78db96ba52620e7a9a0912dd90665 Mon Sep 17 00:00:00 2001 From: Bridget Kromhout Date: Fri, 5 Mar 2021 03:49:15 -0600 Subject: [PATCH 0044/1733] Clarifying dual-stack as default in 1.21. Signed-off-by: Bridget Kromhout --- .../en/docs/concepts/services-networking/dual-stack.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 9bdc756b35..1fcaea4219 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -18,9 +18,9 @@ weight: 70 {{< feature-state for_k8s_version="v1.21" state="beta" >}} - IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. +IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. -If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses. +IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in 1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses. @@ -28,7 +28,7 @@ If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the c ## Supported Features -Enabling IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: +IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) * IPv4 and IPv6 enabled Services @@ -47,6 +47,8 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack ## Configure IPv4/IPv6 dual-stack +To use IPv4/IPv6 dual-stack, ensure the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled for the relevant components of your cluster. (Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled.) + To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments: * kube-apiserver: @@ -63,7 +65,7 @@ An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own ad An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) -Starting in 1.21, IPv4/IPv6 dual-stack defaults to true. +Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled. You can disable it when necessary by specifying `--feature-gates="IPv6DualStack=false"` on the kube-apiserver, kube-controller-manager, kubelet, and kube-proxy command line. {{< /note >}} From 9ac0ee96651dae09fef9667ad9a79fbd8ed7cf7e Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Tue, 2 Mar 2021 21:11:23 -0300 Subject: [PATCH 0045/1733] persistent-volumes.md translation from storage directory --- .../concepts/storage/persistent-volumes.md | 751 ++++++++++++++++++ 1 file changed, 751 insertions(+) create mode 100644 content/pt/docs/concepts/storage/persistent-volumes.md diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000..4ed1fccdfc --- /dev/null +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,751 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +- xing-yang +título: Persistentes Volumes +funcionalidade: + title: Orquestração de Storage + descrição: > + Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + +content_type: conceito +weight: 20 +--- + + + +Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). + + + +## Introdução + +Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. + +Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. + +Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). + +Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. + +Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). + +## Requisição e ciclo de vida de um volume + +PVs são recursos dentro um cluster. PVCs são requisições para esses recursos e também atuam como uma validação da solicitação desses recursos. O ciclo de vida da interação entre PVs e PVCs funcionam da seguinte forma: + +### Provisionamento + +Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. + +#### Stático + +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. + +#### Dinâmico + +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. +Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. + +Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). + +### Binding + +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. + +Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. + +### Utilização + +Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário es +pecifica qual o modo desejado quando utiliza essas requisições. + +Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). + +### Storage Object in Proteção de Uso + +O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. + +{{< note >}} +Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. +{{< /note >}} + +Se um usuário deleta um PVC que está sendo utilizado por um Pod, este PVC não é removido imediatamente. A remoção do PVC é adiada até que o PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a um PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado ao PVC. + +Você pode ver que um PVC é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: + +```shell +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +Você pode ver que um PV é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: + +```shell +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### Recuperação + +Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. + +#### Retenção + +A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: + +1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no storage assset associado. +1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. + +#### Deletar + +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + +#### Reciclar + +{{< warning >}} +A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionametno dinâmico. +{{< /warning >}} + +Em caso do volume plugin ter suporte a essa operação, a política de retenção do `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisiçaõ. + +Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +O Pod reciclador personalizado deve conter a spec `volume` como é mostrado no exemplo abaixo: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "k8s.gcr.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é substituído pelo caminho do volume que está sendo reciclado. + +### Reservando um PersistentVolume + +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que um PVC faça um bind com um PV específco, é preciso fazer o pre-bind deles. + +Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bind entre um PVC e um PV específico. +O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. + +O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. +A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: foo-pvc + namespace: foo +spec: + storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set + volumeName: foo-pv + ... +``` + +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: foo-pv +spec: + storageClassName: "" + claimRef: + name: foo-pvc + namespace: foo + ... +``` + +Isso é útil se você deseja utilizar PersistentVolumes que possuem suas `claimPolicy` configuradas para `Retain`, incluindo situações onde você estiver reutilizando um PV existente. + +### Expandindo Requisições de Persistent Volumes + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +Agora o suporte para expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: + +* gcePersistentDisk +* awsElasticBlockStore +* Cinder +* glusterfs +* rbd +* Azure File +* Azure Disk +* Portworx +* FlexVolumes +* {{< glossary_tooltip text="CSI" term_id="csi" >}} + +Você só pode expandir um PVC se o campo do storage class `allowVolumeExpansion` é true. + +``` yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: gluster-vol-default +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://192.168.10.100:8080" + restusuário: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +Para solicitar um volume maior para um PVC, edite o PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invès disso, um volume existente é redimensionado. + +#### Expansão de volume CSI + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +O suporte à expansão de volumes CSI é habilitada por padrão, porém é necessário um driver CSI específico para suportar a expansão do volume. Verifique a documentação do driver CSI específico para mais informações. + +#### Redimensionando um volume que contém um sistema de arquivo + +Só podem ser redimensionados os volumes que contém os seguintes sistemas de arquivo: XFS, Ext3 ou Ext4. + +Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando PersistentVolumeClaim no modo `ReadWrite`. Expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo suporta expansão online. + +FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. +O FlexVolume pode ser redimensionado na reinicialização do Pod. + +#### Redimensionamento de um PersistentVolumeClaim em uso + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + +{{< note >}} +Expansão de PVCs em uso está disponível como beta desde Kubernetes 1.15, e como alpha desde 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. +{{< /note >}} + +Neste caso você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por um PVC existente. +Automaticamente, qualquer PVC em uso fica disponível para o Pod assim que o sistema de arquivo for expandido. +Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize o PVC antes que a expansão seja completada. + +Da mesma forma que outros tipos de volumes - volumes FlexVolume também podem ser expandidos quando estiverem em uso por um Pod. + +{{< note >}} +Redimensionamento de FlexVolume somente é possível quando o respectivo driver suportar essa operação. +{{< /note >}} + +{{< note >}} +Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é possível fazer uma modificação por volume a cada 6 horas. +{{< /note >}} + +#### Recuperação em caso de falha na expansão de volumes + +Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. + +1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. +2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. +3. Delete a entrada `claimRef` da especificação do PV para que um PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. +4. Recrie o PVC com um tamanho menor que o PV e configure o campo `volumeName` do PCV com o nome do PV. Isso deve fazer o bind de um novo PVC a um PV existente. +5. Não esqueça de restaurar a política de recuperação do PV. + +## Tipos de volumes persistentes. + +Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernetes suporta os plugins abaixo: + +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**depreciado**) +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume +* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk +* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere utilizari volume `local`.) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - storage local montados nos nós. +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage +* `photonPersistentDisk` - Controlador Photon para disco persistente. + (Esse tipo de volume não funciona mais desde a removação do provedor de cloud correspondente.) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Volume Portworx +* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Volume Quobyte +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Volume Rados Block Device (RBD) +* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - Volume ScaleIO + (**depreciado**) +* [`storageos`](/docs/concepts/storage/volumes/#storageos) - Volume StorageOS +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - Volume vSphere VMDK + +## Volumes Persistentes + +Cada PV contém uma spec e um status, que é a espeficiação e o status do volume. O nome de PersistentVolume deve ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)válido. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Reciclar + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +{{< note >}} +Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar /sbin/mount.nfs é necessário para suportar a montagem dos sistemas de arquivos NFS. +{{< /note >}} + +### Capacidade + +Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. + +Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. + +### Modo do Volume + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Block`. + +`volumeMode` é um parâmetro opicional da API. +`Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. + +Um volume com `volumeMode: Filesystem` é *mounted* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. + +Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma cama de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Raw Block Volume Support](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. + +### Modos de Acesso + +Um PersistentVolume pode ser montado num host das mais variadas formas suportadas pelo provedor. Como mostrado na tabela abaixo, os provedores terão diferentes capacidades e cada modo de acesso do PV são configurados nos modos específicos suportados para cada volume em particular. Por exemplo, o NFS pode suportar múltiplos clientes read/write, mas um PV NFS específico pode ser exportado no server como read-only. Cada PV recebe seu próprio modo de acesso que descreve suas capacidades específicas. + +Os modos de acesso são: + +* ReadWriteOnce -- o volume pode ser montado como read-write por um nó único +* ReadOnlyMany -- o volume pode ser montado como ready-only por vários nós +* ReadWriteMany -- o volume pode ser montado como read-write por vários nós + +Na linha de comando, os modos de acesso ficam abreviados: + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany + +> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não ao mesmo tempo. + + +| Plugin de Volume | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| +| :--- | :---: | :---: | :---: | +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| CSI | depende do driver | depende do driver | depende do driver | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | depende do driver | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | - (funcionam quando os Pods são do tipo collocated) | +| PortworxVolume | ✓ | - | ✓ | +| ScaleIO | ✓ | ✓ | - | +| StorageOS | ✓ | - | - | + +### Classe + +Um PV pode ter uma classe, que é especificada na configuração do atribute `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possuí nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. + +No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. + +### Política de Retenção + +Atuamente as políticas de retenção são: + +* Retenção -- recuperação manual +* Reciclar -- limpeza básica (`rm -rf /thevolume/*`) +* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted + +Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. + +### Opções de Montagem + +Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Persistent Volume é montado num nó. + +{{< note >}} +Nem todos os tipos de Persistent Volume suportam opções de montagem. +{{< /note >}} + +Seguem os tipos de volumes que suportam opções de montagem. + +* AWSElasticBlockStore +* AzureDisk +* AzureFile +* CephFS +* Cinder (OpenStack block storage) +* GCEPersistentDisk +* Glusterfs +* NFS +* Quobyte Volumes +* RBD (Ceph Block Device) +* StorageOS +* VsphereVolume +* iSCSI + +Não há validação em relação às opções de montagem. A montagem irá falhar se houver uma opção de montagem inválida. + +No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. + +### Afinidade de Nó + +{{< note >}} +Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes do tipo bloco: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +{{< /note >}} + +Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. + +### Estado + +Um volume sempre estará em dos seguintes estados: + +* Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição +* Bound -- um volume atrelado a uma requisição +* Released -- a requisião foi deletada, mas o curso ainda não foi recuperado pelo cluster +* Failed -- o volume fracassou na sua recuperação automática + + +A CLI mostrará o nome do PV que foi atrelado ao PVC +The CLI will show the name of the PVC bound to the PV. + +## PersistentVolumeClaims + +Cada PVC contém uma spec e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### Modos de Acesso + +As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. + +### Modos de Volume + +As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. + +### Recursos + +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. + +### Selector + +Requisições podem especifiar um [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam labels que safistaçam os critérios do selector podem ser atreladas à requisição. O selector podem conter dois campos: + +* `matchLabels` - o volume deve ter uma label com esse valor +* `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. + +Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - todos eles juntos devem ser atendidos. + +### Classe + +Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. + +Os PVCs não precisam necessariamente solicitar uma classe. Um PVC com seu `storageClassName` configurado como `""` sempre vai solicitar um PV sem classe, dessa forma ele sempre será atrelado a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Um PVC sem `storageClassName` não é a mesma coisa e será tratado pelo cluster de forma diferente, porém isso vai depender se o [`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) estiver habilitado. + +* Se o admission plugin estiver habilitado, o administrador pode especificar o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` podem ser atrelados somente a PVs que atendam a essa padrão. A especificação de um StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto do StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de um PVC como se o admission plugin estivesse desabilitado. Se mais de um valor padrão for especificado, o admission plugin proíbe a criação de todos os PVCs. +* Se o admission plugin estiver desabilitado, não haverá nenhuma notação para o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` poderão ser atrelados somente aos PVs que não possuem classe.Neste caso, os PVCs que não tiverem `storageClassName` são tratados da mesma forma como os PVCs que possuem seus `storageClassName` configurados como `""`. + +Dependendo do modo de instalação, um StorageClass padrão pode ser deployed num cluster Kubernetes durante a instalação pelo addon manager. + +Quando um PVC especifica um `selector` para solicitar um StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com a label requisistada pode ser atrelado ao PVC. + +{{< note >}} +Atualmente, um PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. +{{< /note >}} + +No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atribute `storageClassName` Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. + +## Requisições como Volumes + +Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### Sobre Namespaces + +Os binds dos PersistentVolumes são exclusivos e desde que PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. + +### PersistentVolumes do tipo `hostPath` + +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). +A `hostPath` PersistentVolume uses a file or directory on the Node to emulate network-attached storage. Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). + + +## Raw Block Volume Support + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + + +Os plugins de volume abaixo suportam raw block volumes, incluindo provisionamento dinâmico onde for possível: +applicable: + +* AWSElasticBlockStore +* AzureDisk +* CSI +* FC (Fibre Channel) +* GCEPersistentDisk +* iSCSI +* Local volume +* OpenStack Cinder +* RBD (Ceph Block Device) +* VsphereVolume + + +### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` + +### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + + +### Pod specification adding Raw Block Device path in container + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} + +Quando adicionar a raw block device para um Pod, você especifica o caminho do dispositivo no container ao invés de um mount path +{{< /note >}} + +### Bind de Volumes de Bloco + +Se um usuário solicita um raw block volume através do campo `volumeMode` na spec do PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não vão considerar esse modo como parte da spec. + +A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um raw block device. A tabela indica se o volume será ou não atrelado com base nas combinações: +Matrix de bind de volume para provisionamento estático de volumes: + +| PV volumeMode | PVC volumeMode | Result | +| --------------|:---------------:| ----------------:| +| unspecified | unspecified | BIND | +| unspecified | Block | NO BIND | +| unspecified | Filesystem | BIND | +| Block | unspecified | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | unspecified | BIND | + +{{< note >}} + +O provisionamento estático de volumes é suportado somente na versão alpha. Administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com raw block devices. +{{< /note >}} + +## Snapshot de Volume e Restauração de Volume a partir de um Snapshot + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Volume Snapshots](/docs/concepts/storage/volume-snapshots/) para mais detalhes. +Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### Criar um PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Clonagem de Volume + +[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins. + +### Criação de PersistentVolumeClaim a partir de um PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Boas Práticas de Configuração + +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: + +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). +- Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. + the config may not have permission to create PersistentVolumes. +- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. + - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). + + ## {{% heading "whatsnext" %}} + + +* Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +* Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). +* Leia a [documentação sobre plajemamento de Storage Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). + +### Referência + +* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) +* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) + From 16793b7e7f011398fb885a7d280ea41f7f15ec72 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Fri, 5 Mar 2021 01:09:20 -0300 Subject: [PATCH 0046/1733] Fix word translations about push request #26806 --- .../concepts/storage/persistent-volumes.md | 58 +++++++++---------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 4ed1fccdfc..76341bed46 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -7,9 +7,9 @@ reviewers: - xing-yang título: Persistentes Volumes funcionalidade: - title: Orquestração de Storage + title: Orquestração de Armazenamento descrição: > - Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. content_type: conceito weight: 20 @@ -23,13 +23,13 @@ Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. S ## Introdução -Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +Gerenciamento armazenamento é uma questão bem diferente de gerenciamento de instâncias computacionais. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. -Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. +Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. -Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). +Um _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). -Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. +Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de armazenamento de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). @@ -43,18 +43,18 @@ Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. #### Stático -O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. #### Dinâmico Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. -Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. @@ -65,9 +65,9 @@ pecifica qual o modo desejado quando utiliza essas requisições. Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). -### Storage Object in Proteção de Uso +### Objeto de Armazenamento em Proteção de Uso -O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. +O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. {{< note >}} Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. @@ -121,13 +121,13 @@ Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: -1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. -1. Limpar os dados de forma manual no storage assset associado. -1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. +1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no armazenamento associado. +1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. #### Deletar -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar @@ -171,7 +171,7 @@ Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bin O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. -A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. +A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. ```yaml apiVersion: v1 @@ -185,7 +185,7 @@ spec: ... ``` -Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. ```yaml apiVersion: v1 @@ -276,7 +276,7 @@ Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é pos #### Recuperação em caso de falha na expansão de volumes -Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. +Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. 1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. 2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. @@ -346,9 +346,9 @@ Talvez sejam necessários programas auxiliares para um determinado tipo de volum ### Capacidade -Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. +Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. -Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. +Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. ### Modo do Volume @@ -417,7 +417,7 @@ Atuamente as políticas de retenção são: * Retenção -- recuperação manual * Reciclar -- limpeza básica (`rm -rf /thevolume/*`) -* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted +* Delete -- armazenamento associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. @@ -496,7 +496,7 @@ spec: ### Modos de Acesso -As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. +As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. ### Modos de Volume @@ -504,7 +504,7 @@ As requisições usam as mesmas convenções que os volumes quando eles indicam ### Recursos -Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. ### Selector @@ -536,7 +536,7 @@ No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no l ## Requisições como Volumes -Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. +Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. ```yaml apiVersion: v1 @@ -726,15 +726,15 @@ spec: ## Boas Práticas de Configuração -Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize a estrutura abaixo: - Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. the config may not have permission to create PersistentVolumes. -- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. - - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. - - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). +- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instaciar o template. + - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de armazenamento correta se o cluster tiver o StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de armazenamento (que no caso, o usuário não pode fazer deploy solicitando PVCs). ## {{% heading "whatsnext" %}} From 8bd82abd9feeb996a0eff10c43c60da99fc19b63 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Tue, 2 Mar 2021 21:11:23 -0300 Subject: [PATCH 0047/1733] persistent-volumes.md translation from storage directory --- .../concepts/storage/persistent-volumes.md | 85 ++++++++++++++++++- 1 file changed, 84 insertions(+), 1 deletion(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 76341bed46..98356ee15a 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -10,6 +10,9 @@ funcionalidade: title: Orquestração de Armazenamento descrição: > Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + title: Orquestração de Storage + descrição: > + Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. content_type: conceito weight: 20 @@ -23,6 +26,7 @@ Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. S ## Introdução + Gerenciamento armazenamento é uma questão bem diferente de gerenciamento de instâncias computacionais. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. @@ -31,6 +35,15 @@ Um _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um u Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de armazenamento de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. +Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. + +Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. + +Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). + +Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. + + Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). ## Requisição e ciclo de vida de um volume @@ -43,19 +56,31 @@ Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. #### Stático + O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. + + #### Dinâmico Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. + Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). + +### Binding + +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. + + Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. ### Utilização @@ -65,10 +90,16 @@ pecifica qual o modo desejado quando utiliza essas requisições. Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). + ### Objeto de Armazenamento em Proteção de Uso O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. +### Storage Object in Proteção de Uso + +O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. + + {{< note >}} Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. {{< /note >}} @@ -121,6 +152,7 @@ Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: + 1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. 1. Limpar os dados de forma manual no armazenamento associado. 1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. @@ -129,6 +161,15 @@ A política de `Retain` permite a recuperação de forma manual do recurso. Quan Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no storage assset associado. +1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. + +#### Deletar + +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + + #### Reciclar {{< warning >}} @@ -171,8 +212,12 @@ Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bin O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. + A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. +A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. + + ```yaml apiVersion: v1 kind: PersistentVolumeClaim @@ -185,8 +230,12 @@ spec: ... ``` + Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. + + ```yaml apiVersion: v1 kind: PersistentVolume @@ -276,8 +325,12 @@ Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é pos #### Recuperação em caso de falha na expansão de volumes + Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. +Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. + + 1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. 2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. 3. Delete a entrada `claimRef` da especificação do PV para que um PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. @@ -346,10 +399,16 @@ Talvez sejam necessários programas auxiliares para um determinado tipo de volum ### Capacidade + Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. +Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. + +Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. + + ### Modo do Volume {{< feature-state for_k8s_version="v1.18" state="stable" >}} @@ -417,8 +476,12 @@ Atuamente as políticas de retenção são: * Retenção -- recuperação manual * Reciclar -- limpeza básica (`rm -rf /thevolume/*`) + * Delete -- armazenamento associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted +* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted + + Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. ### Opções de Montagem @@ -496,16 +559,24 @@ spec: ### Modos de Acesso + As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. +As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. + + ### Modos de Volume As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. ### Recursos + Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. + + ### Selector Requisições podem especifiar um [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam labels que safistaçam os critérios do selector podem ser atreladas à requisição. O selector podem conter dois campos: @@ -536,8 +607,12 @@ No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no l ## Requisições como Volumes + Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. +Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. + + ```yaml apiVersion: v1 kind: Pod @@ -726,8 +801,12 @@ spec: ## Boas Práticas de Configuração + Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize a estrutura abaixo: +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: + + - Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. the config may not have permission to create PersistentVolumes. @@ -735,6 +814,11 @@ Se você está criando templates ou exemplos que rodam numa grande quantidade de - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de armazenamento correta se o cluster tiver o StorageClasses habilitado pelo administrador. - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. - Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de armazenamento (que no caso, o usuário não pode fazer deploy solicitando PVCs). +- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. + - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). + ## {{% heading "whatsnext" %}} @@ -748,4 +832,3 @@ Se você está criando templates ou exemplos que rodam numa grande quantidade de * [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) - From 1e77a684c2c0b622d2a19f976a16654dca9c6b2f Mon Sep 17 00:00:00 2001 From: Andy Zhang Date: Sun, 7 Mar 2021 21:28:40 +0800 Subject: [PATCH 0048/1733] Update content/en/docs/concepts/storage/volumes.md Co-authored-by: Tim Bannister --- content/en/docs/concepts/storage/volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index d7eb7a1679..664ba515f9 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -159,7 +159,7 @@ from the existing in-tree plugin to the `file.csi.azure.com` Container Storage Interface (CSI) Driver. In order to use this feature, the [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile` -features must be enabled. +[feature gates](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled. ### cephfs From ce4d342369f3c61ed5a73751f586c3cad26c8f55 Mon Sep 17 00:00:00 2001 From: Soichiro KAWAMURA Date: Sun, 7 Mar 2021 23:00:31 +0900 Subject: [PATCH 0049/1733] add Japanese translation of pod-priority-preemption.md --- .../configuration/pod-priority-preemption.md | 241 ++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 content/ja/docs/concepts/configuration/pod-priority-preemption.md diff --git a/content/ja/docs/concepts/configuration/pod-priority-preemption.md b/content/ja/docs/concepts/configuration/pod-priority-preemption.md new file mode 100644 index 0000000000..eb2ee65956 --- /dev/null +++ b/content/ja/docs/concepts/configuration/pod-priority-preemption.md @@ -0,0 +1,241 @@ +--- +title: Podの優先度とプリエンプション +content_type: concept +weight: 70 +--- + + + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +[Pod](/docs/concepts/workloads/pods/)は _priority_（優先度）を持つことができます。 +優先度は他のPodに対する相対的なPodの重要度を示します。 +もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする（追い出す）ことを試みます。 + + + + + + +{{< warning >}} +クラスターの全てのユーザーが信用されていない場合、悪意のあるユーザーが可能な範囲で最も高い優先度のPodを作成することが可能です。これは他のPodが追い出されたりスケジューリングできない状態を招きます。 +管理者はResourceQuotaを使用して、ユーザーがPodを高い優先度で作成することを防ぐことができます。 + +詳細は[デフォルトで優先度クラスの消費を制限する](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) +を参照してください。 +{{< /warning >}} + +## 優先度とプリエンプションを使う方法 + +優先度とプリエンプションを使うには、 + +1. 1つまたは複数の[PriorityClass](#priorityclass)を追加します + +1. 追加したPriorityClassを[`priorityClassName`](#pod-priority)に設定したPodを作成します。 + もちろんPodを直接作る必要はありません。 + 一般的には`priorityClassName`をDeploymentのようなコレクションオブジェクトのPodテンプレートに追加します。 + +これらの手順のより詳しい情報については、この先を読み進めてください。 + +{{< note >}} +Kubernetesには最初から既に2つのPriorityClassが設定された状態になっています。 +`system-cluster-critical`と`system-node-critical`です。 +これらは汎用のクラスであり、[重要なコンポーネントが常に最初にスケジュールされることを保証する](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)ために使われます。 +{{< /note >}} + +## PriorityClass + +PriorityClassはnamespaceによらないオブジェクトで、優先度クラスの名称から優先度を表す整数値への対応を定義します。 +PriorityClassオブジェクトのメタデータの`name`フィールドにて名称を指定します。 +値は`value`フィールドで指定し、必須です。 +値が大きいほど、高い優先度を示します。 +PriorityClassオブジェクトの名称は[DNSサブドメイン名](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)として適切であり、かつ`system-`から始まらないことが必要です。 + +PriorityClassオブジェクトは10億以下の任意の32ビットの整数値を持つことができます。 +それよりも大きな値は通常はプリエンプトや追い出すべきではない重要なシステム用のPodのために予約されています。 +クラスターの管理者は割り当てたい優先度に対して、PriorityClassオブジェクトを1つずつ作成すべきです。 + +PriorityClassは任意でフィールド`globalDefault`と`description`を設定可能です。 +`globalDefault`フィールドは`priorityClassName`が指定されないPodはこのPriorityClassを使うべきであることを示します。`globalDefault`が設定されたPriorityClassはシステムで一つのみ存在可能です。`globalDefault`が設定されたPriorityClassが存在しない場合は、`priorityClassName`が設定されていないPodの優先度は0に設定されます。 + +`description`フィールドは任意の文字列です。クラスターの利用者に対して、PriorityClassをどのような時に使うべきか示すことを意図しています。 + +### PodPriorityと既存のクラスターに関する注意 + +- もし既存のクラスターをこの機能がない状態でアップグレードすると、既存のPodの優先度は実質的に0になります。 + +- `globalDefault`が`true`に設定されたPriorityClassを追加しても、既存のPodの優先度は変わりません。PriorityClassのそのような値は、PriorityClassが追加された以後に作成されたPodのみに適用されます。 + +- PriorityClassを削除した場合、既存のPodは削除されたPriorityClassの名称を引き続き使用しますが、削除されたPriorityClassの名称を使うPodをそれ以上作成することはできなくなります。 + +### PriorityClassの例 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority +value: 1000000 +globalDefault: false +description: "この優先度クラスはXYZサービスのPodに対してのみ使用すべきです。" +``` + +## 非プリエンプトのPriorityClass {#non-preempting-priority-class} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +`PreemptionPolicy: Never`と設定されたPodは、スケジューリングのキューにおいて他の優先度の低いPodよりも優先されますが、他のPodをプリエンプトすることはありません。 +スケジューリングされるのを待つ非プリエンプトのPodは、リソースが十分に利用可能になるまでスケジューリングキューに残ります。 +非プリエンプトのPodは、他のPodと同様に、スケジューラーのバックオフの対象になります。これは、スケジューラーがPodをスケジューリングしようと試みたものの失敗した場合、低い頻度で再試行するようにして、より優先度の低いPodが先にスケジューリングされることを許します。 + +非プリエンプトのPodは、他の優先度の高いPodにプリエンプトされる可能性はあります。 + +`PreemptionPolicy`はデフォルトでは`PreemptLowerPriority`に設定されており、これが設定されているPodは優先度の低いPodをプリエンプトすることを許容します。これは既存のデフォルトの挙動です。 +`PreemptionPolicy`を`Never`に設定すると、これが設定されたPodはプリエンプトを行わないようになります。 + +ユースケースの例として、データサイエンスの処理を挙げます。 +ユーザーは他の処理よりも優先度を高くしたいジョブを追加できますが、そのとき既存の実行中のPodの処理結果をプリエンプトによって捨てさせたくはありません。 +`PreemptionPolicy: Never`が設定された優先度の高いジョブは、他の既にキューイングされたPodよりも先に、クラスターのリソースが「自然に」開放されたときにスケジューリングされます。 + +### 非プリエンプトのPriorityClassの例 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority-nonpreempting +value: 1000000 +preemptionPolicy: Never +globalDefault: false +description: "この優先度クラスは他のPodをプリエンプトさせません。" +``` + +## Podの優先度 + +一つ以上のPriorityClassがあれば、仕様にPriorityClassを指定したPodを作成することができるようになります。優先度のアドミッションコントローラーは`priorityClassName`フィールドを使用し、優先度の整数値を設定します。PriorityClassが見つからない場合、そのPodの作成は拒否されます。 + +下記のYAMLは上記の例で作成したPriorityClassを使用するPodの設定の例を示します。優先度のアドミッションコントローラーは仕様を確認し、このPodの優先度は1000000であると設定します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + priorityClassName: high-priority +``` + +### スケジューリング順序におけるPodの優先度の効果 + +Podの優先度が有効な場合、スケジューラーは待機状態のPodをそれらの優先度順に並べ、スケジューリングキューにおいてより優先度の低いPodよりも前に来るようにします。その結果、その条件を満たしたときには優先度の高いPodは優先度の低いPodより早くスケジューリングされます。優先度の高いPodがスケジューリングできない場合は、スケジューラーは他の優先度の低いPodのスケジューリングも試みます。 + +## プリエンプション + +Podが作成されると、スケジューリング待ちのキューに入り待機状態になります。スケジューラーはキューからPodを取り出し、ノードへのスケジューリングを試みます。Podに指定された条件を全て満たすノードが見つからない場合は、待機状態のPodのためにプリエンプションロジックが発動します。待機状態のPodをPと呼ぶことにしましょう。プリエンプションロジックはPよりも優先度の低いPodを一つ以上追い出せばPをスケジューリングできるようになるノードを探します。そのようなノードがあれば、優先度の低いPodはノードから追い出されます。Podが追い出された後に、Pはノードへスケジューリング可能になります。 + +### ユーザーへ開示される情報 + +Pod PがノードNのPodをプリエンプトした場合、ノードNの名称がPのステータスの`nominatedNodeName`フィールドに設定されます。このフィールドはスケジューラーがPod Pのために予約しているリソースの追跡を助け、ユーザーにクラスターにおけるプリエンプトに関する情報を与えます。 + +Pod Pは「指名したノード」へスケジューリングされる必要はないことに注意してください。Podがプリエンプトされると、そのPodは猶予期間を得ます。スケジューラーがPodの終了を待つ間に他のノードが利用可能になると、スケジューラーは他のノードをPod Pのスケジューリング先にします。この結果、Podの`nominatedNodeName`と`nodeName`は必ずしも一致しません。また、スケジューラーがノードNのPodをプリエンプトさせた後に、Pod Pよりも優先度の高いPodが来た場合、スケジューラーはノードNをその新しい優先度の高いPodへ与えます。このような場合は、スケジューラーはPod Pの`nominatedNodeName`を消去します。これによって、スケジューラーはPod Pが他のノードのPodをプリエンプトさせられるようにします。 + +### プリエンプトの制限 + +#### プリエンプトされるPodの正常終了 + +Podがプリエンプトされると、[猶予期間](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)が与えられます。 + +Podは作業を完了し、終了するために十分な時間が与えられます。仮にそうでない場合、強制終了されます。この猶予期間によって、スケジューラーがPodをプリエンプトした時刻と、待機状態のPod Pがノード Nにスケジュール可能になるまでの時刻の間に間が開きます。この間、スケジューラーは他の待機状態のPodをスケジュールしようと試みます。プリエンプトされたPodが終了したら、スケジューラーは待ち行列にあるPodをスケジューリングしようと試みます。そのため、Podがプリエンプトされる時刻と、Pがスケジュールされた時刻には間が開くことが一般的です。この間を最小にするには、優先度の低いPodの猶予期間を0または小さい値にする方法があります。 + +#### PodDisruptionBudgetは対応するが、保証されない + +[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)は、アプリケーションのオーナーが冗長化されたアプリケーションのPodが意図的に中断される数の上限を設定できるようにするものです。KubernetesはPodをプリエンプトする際にPDBに対応しますが、PDBはベストエフォートで考慮します。スケジューラーはプリエンプトさせたとしてもPDBに違反しないPodを探します。そのようなPodが見つからない場合でもプリエンプションは実行され、PDBに反しますが優先度の低いPodが追い出されます。 + +#### 優先度の低いPodにおけるPod間のアフィニティ + +次の条件が真の場合のみ、ノードはプリエンプションの候補に入ります。 +「待機状態のPodよりも優先度の低いPodをノードから全て追い出したら、待機状態のPodをノードへスケジュールできるか」 + +{{< note >}} +プリエンプションは必ずしも優先度の低いPodを全て追い出しません。 +優先度の低いPodを全て追い出さなくても待機状態のPodがスケジューリングできる場合、一部のPodのみ追い出されます。 +このような場合であったとしても、上記の条件は真である必要があります。偽であれば、そのノードはプリエンプションの対象とはされません。 +{{< /note >}} + +待機状態のPodが、優先度の低いPodとの間でPod間のアフィニティを持つ場合、Pod間のアフィニティはそれらの優先度の低いPodがなければ満たされません。この場合、スケジューラーはノードのどのPodもプリエンプトしようとはせず、代わりに他のノードを探します。スケジューラーは適切なノードを探せる場合と探せない場合があります。この場合、待機状態のPodがスケジューリングされる保証はありません。 + +この問題に対して推奨される解決策は、優先度が同一または高いPodに対してのみPod間のアフィニティを作成することです。 + +#### 複数ノードに対するプリエンプション + +Pod PがノードNにスケジューリングできるよう、ノードNがプリエンプションの対象となったとします。 +他のノードのPodがプリエンプトされた場合のみPが実行可能になることもあります。下記に例を示します。 + +* Pod PをノードNに配置することを検討します。 +* Pod QはノードNと同じゾーンにある別のノードで実行中です。 +* Pod Pはゾーンに対するQへのアンチアフィニティを持ちます (`topologyKey: topology.kubernetes.io/zone`)。 +* Pod Pと、ゾーン内の他のPodに対しては他のアンチアフィニティはない状態です。 +* Pod PをノードNへスケジューリングするには、Pod Qをプリエンプトすることが考えられますが、スケジューラーは複数ノードにわたるプリエンプションは行いません。そのため、Pod PはノードNへはスケジューリングできないとみなされます。 + +Pod Qがそのノードから追い出されると、Podアンチアフィニティに違反しなくなるので、Pod PはノードNへスケジューリング可能になります。 + +複数ノードに対するプリエンプションに関しては、十分な需要があり、合理的な性能を持つアルゴリズムを見つけられた場合に、追加することを検討する可能性があります。 + +## トラブルシューティング + +Podの優先度とプリエンプションは望まない副作用をもたらす可能性があります。 +いくつかの起こりうる問題と、その対策について示します。 + +### Podが不必要にプリエンプトされる + +プリエンプションは、リソースが不足している場合に優先度の高い待機状態のPodのためにクラスターの既存のPodを追い出します。 +誤って高い優先度をPodに割り当てると、意図しない高い優先度のPodはクラスター内でプリエンプションを引き起こす可能性があります。Podの優先度はPodの仕様の`priorityClassName`フィールドにて指定されます。優先度を示す整数値へと変換された後、`podSpec`の`priority`へ設定されます。 + +この問題に対処するには、Podの`priorityClassName`をより低い優先度に変更するか、このフィールドを未設定にすることができます。`priorityClassName`が未設定の場合、デフォルトでは優先度は0とされます。 + +Podがプリエンプトされたとき、プリエンプトされたPodのイベントが記録されます。 +プリエンプションはPodに必要なリソースがクラスターにない場合のみ起こるべきです。 +このような場合、プリエンプションはプリエンプトされるPodよりも待機状態のPodの優先度が高い場合のみ発生します。 +プリエンプションは待機状態のPodがない場合や待機状態のPodがプリエンプト対象のPod以下の優先度を持つ場合には決して発生しません。そのような状況でプリエンプションが発生した場合、問題を報告してください。 + +### Podはプリエンプトされたが、プリエンプトさせたPodがスケジューリングされない + +Podがプリエンプトされると、それらのPodが要求した猶予期間が与えられます。そのデフォルトは30秒です。 +Podがその期間内に終了しない場合、強制終了されます。プリエンプトされたPodがなくなれば、プリエンプトさせたPodはスケジューリング可能です。 + +プリエンプトさせたPodがプリエンプトされたPodの終了を待っている間に、より優先度の高いPodが同じノードに対して作成されることもあります。この場合、スケジューラーはプリエンプトさせたPodの代わりに優先度の高いPodをスケジューリングします。 + +これは予期された挙動です。優先度の高いPodは優先度の低いPodに取って代わります。 + +### 優先度の高いPodが優先度の低いPodより先にプリエンプトされる + +スケジューラーは待機状態のPodが実行可能なノードを探します。ノードが見つからない場合、スケジューラーは任意のノードから優先度の低いPodを追い出し、待機状態のPodのためのリソースを確保しようとします。 +仮に優先度の低いPodが動いているノードが待機状態のPodを動かすために適切ではない場合、スケジューラーは他のノードで動いているPodと比べると、優先度の高いPodが動いているノードをプリエンプションの対象に選ぶことがあります。この場合もプリエンプトされるPodはプリエンプトを起こしたPodよりも優先度が低い必要があります。 + +複数のノードがプリエンプションの対象にできる場合、スケジューラーは優先度が最も低いPodのあるノードを選ぼうとします。しかし、そのようなPodがPodDisruptionBudgetを持っており、プリエンプトするとPDBに反する場合はスケジューラーは優先度の高いPodのあるノードを選ぶこともあります。 + +複数のノードがプリエンプションの対象として利用可能で、上記の状況に当てはまらない場合、スケジューラーは優先度の最も低いノードを選択します。 + +## Podの優先度とQoSの相互作用 {#interactions-of-pod-priority-and-qos} + +Podの優先度と{{< glossary_tooltip text="QoSクラス" term_id="qos-class" >}}は直交する機能で、わずかに相互作用がありますが、デフォルトではQoSクラスによる優先度の設定の制約はありません。スケジューラーのプリエンプションのロジックはプリエンプションの対象を決めるときにQoSクラスは考慮しません。 +プリエンプションはPodの優先度を考慮し、優先度が最も低いものを候補とします。より優先度の高いPodは優先度の低いPodを追い出すだけではプリエンプトを起こしたPodのスケジューリングに不十分な場合と、`PodDisruptionBudget`により優先度の低いPodが保護されている場合のみ対象になります。 + +QoSとPodの優先度の両方を考慮するコンポーネントは[リソース不足によりkubeletがPodを追い出す](/docs/tasks/administer-cluster/out-of-resource/)のみです。 +kubeletは追い出すPodの順位付けを次の順で行います。枯渇したリソースを要求以上に使用しているか、優先度、枯渇したリソースの消費量の複数のPodの要求に対する相対値。 +詳細は[エンドユーザーのPodの追い出し](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)を参照してください。 + + +kubeletによるリソース不足時のPodの追い出しでは、リソースの消費が要求を超えないPodは追い出されません。優先度の低いPodのリソースの利用量がその要求を超えていなければ、追い出されることはありません。より優先度が高く、要求を超えてリソースを使用しているPodが追い出されます。 + + +## {{% heading "whatsnext" %}} + +* PriorityClassと関連付けてResourceQuotaを使用することに関して [デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) + From 6b8f15bd22ca0a458d64d4c2f3a05cdd5312a711 Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Sun, 7 Mar 2021 15:35:38 -0300 Subject: [PATCH 0050/1733] Fixing push request #26806 recommendations and I made some improvement on the translation --- .../concepts/storage/persistent-volumes.md | 312 ++++++------------ 1 file changed, 108 insertions(+), 204 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 98356ee15a..7236c4c56d 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -5,14 +5,11 @@ reviewers: - thockin - msau42 - xing-yang -título: Persistentes Volumes -funcionalidade: +title: Volumes Persistentes +feature: title: Orquestração de Armazenamento - descrição: > + description: > Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. - title: Orquestração de Storage - descrição: > - Mountar automaticamente o storage de sua escolha, seja de um storage local, de um provedor de cloud pública, como GCP ou AWS, ou um storage de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. content_type: conceito weight: 20 @@ -20,29 +17,20 @@ weight: 20 -Esse documento descreve o estado atual dos _persistent volumes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). +Esse documento descreve o estado atual dos _volumes persistentes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). ## Introdução -Gerenciamento armazenamento é uma questão bem diferente de gerenciamento de instâncias computacionais. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsitema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. -Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. +Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. -Um _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). - -Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de armazenamento de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. - -Gerenciamento storage é uma questão bem diferente de gerenciamento de compute instances. O PersistentVolume subsystem provê uma API para usuários e administradores que mostra de forma detalhada de como o storage é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. - -Um _PersistentVolume_ (PV) é uma parte do storage dentro do cluster que tenha sido provisionada por um administrador ou dinamicamente utilizando [Storage Classes](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó é um recurso dentro do cluster. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do storage, seja ele NFS, iSCSI, ou um storage específico de um provedor de cloud pública. - -Um _PersistentVolumeClaim_ (PVC) é uma requisição para storage por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem requisitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [AccessModes](#access-modes)). - -Enquanto PersistentVolumeClaims permite que um usuário utilize recursos de storage de forma abstrata, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essa, temos o recurso de _StorageClass_. +Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). +Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). @@ -52,61 +40,41 @@ PVs são recursos dentro um cluster. PVCs são requisições para esses recursos ### Provisionamento -Existem duas formas de provisionar ujm PV: staticamente ou dinamicamente. - -#### Stático +Existem duas formas de provisionar um PV: staticamente ou dinamicamente. +#### Estático O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. -O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do storage a qual estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. - - #### Dinâmico -Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de um PersistentVolumeClaim enviado por um usário, o cluster pode tentar realizar um provisionamento dinâmico para atender a esse PVC. -Esse provisionamento é baseado em StorageClasses: o PVC deve solicitar um [storage class](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. - -Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. -Para habilitar o provisionamento de storage dinâmico baseado em storage class, o administrador do cluster precisa habilitar a `DefaultStorageClass` [admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre ndo das flags do servidor de API, consulte a documentação do [kube-apiserver](/docs/admin/kube-apiserver/). - -### Binding - -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, um PersistentVolumeClaim solicitando uma quantidade específica de storage e um determinado modo de acesso. Um controle de loop no master monitora por novos PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por um PVC, o loop sempre vai fazer o bind desse PV com esse específico PVC. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre um PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. - - -Requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de um PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. +As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. ### Utilização -Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário es -pecifica qual o modo desejado quando utiliza essas requisições. +Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário especifica qual o modo desejado quando utiliza essas requisições. -Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Claims As Volumes](#claims-as-volumes). +Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Requisições como Volumes](#requisições-como-volumes). +### Proteção de Uso de um Objeto de Armazenamento -### Objeto de Armazenamento em Proteção de Uso - -O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. - -### Storage Object in Proteção de Uso - -O propósito da funcionalidade do Storage Object in Use Protection é garantir que PersistentVolumeClaims (PVCs) que estejam sendo utilizados por um Pod e PersistentVolume (PVs) que pertecem aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. - +O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que as PersistentVolumeClaims (PVCs) que estejam sendo utilizadas por um Pod e PersistentVolume (PVs) que pertençam aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. {{< note >}} -Um PVC está sendo utilizado por um Pod quando existe um Pod que está usando esse PVC. +Uma PVC está sendo utilizada por um Pod quando existe um Pod que está usando essa PVC. {{< /note >}} -Se um usuário deleta um PVC que está sendo utilizado por um Pod, este PVC não é removido imediatamente. A remoção do PVC é adiada até que o PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a um PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado ao PVC. +Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. -Você pode ver que um PVC é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: +Você pode ver que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: ```shell kubectl describe pvc hostpath @@ -122,7 +90,7 @@ Finalizers: [kubernetes.io/pvc-protection] ... ``` -Você pode ver que um PV é protegido quando o status do PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: +Você pode ver que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: ```shell kubectl describe pv task-pv-volume @@ -146,11 +114,11 @@ Events: ### Recuperação -Quando um usuário não precisar mais utilizar um volume, ele pode deletar o PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. +Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. #### Retenção -A política de `Retain` permite a recuperação de forma manual do recurso. Quando o PersistentVolumeClaim é deletado, ele continua existindo e o volume é considerado "liberado". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: +A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: 1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. @@ -159,16 +127,7 @@ A política de `Retain` permite a recuperação de forma manual do recurso. Quan #### Deletar -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). - -1. Deletar o PersistentVolume. O storage assset associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. -1. Limpar os dados de forma manual no storage assset associado. -1. Deletar manualmente o storage associado. Caso você queira utilizar o mesmo storage asset, crie um novo PersistentVolume com esse storage asset. - -#### Deletar - -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto PersistentVolume do Kubernetes, quanto o storage asset associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam o [reclaim policy of their StorageClass](#reclaim-policy), que é `Delete` por padrão. O administrador precisa configurar o StorageClass de acordo com as necessidades dos usuários; caso contrário, o PV deve ser editado or reparado após sua criação. Veja [Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). - +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de renteção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar @@ -176,9 +135,9 @@ Para plugins de volume que suportam a política de recuperação `Delete`, a del A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionametno dinâmico. {{< /warning >}} -Em caso do volume plugin ter suporte a essa operação, a política de retenção do `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisiçaõ. +Em caso do volume plugin ter suporte a essa operação, a política de retenção `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisição. -Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [referência](/docs/reference/command-line-tools-reference/kube-controller-manager/). O Pod reciclador personalizado deve conter a spec `volume` como é mostrado no exemplo abaixo: ```yaml @@ -206,17 +165,11 @@ Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é ### Reservando um PersistentVolume -A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que um PVC faça um bind com um PV específco, é preciso fazer o pre-bind deles. +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específco, é preciso fazer o pré-bind deles. -Especificando um PersistentVolume no PersistentVolumeClaim, você declara um bind entre um PVC e um PV específico. -O bind ocorrerá se o PersistentVolume existir e não estiver reservado por um PersistentVolumeClaims através do seu campo `claimRef`. - -O bind ocorre independente de algum volume atender ao critério, incluindo afinidade de nó. - -A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. - -A camada de gerenciamento verifica se a [storage class](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do storage solicitado ainda são válidos. +Especificando um PersistentVolume na PersistentVolumeClaim, você declara um bind entre uma PVC e um PV específico. O bind ocorrerá se o PersistentVolume existir e não estiver reservado por uma PersistentVolumeClaims através do seu campo `claimRef`. +O bind ocorre independentemente se algum volume atender ao critério, incluindo afinidade de nó. A camada de gerenciamento verifica se a [classe de armazenamento](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. ```yaml apiVersion: v1 @@ -230,11 +183,7 @@ spec: ... ``` - -Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. - -Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que algum outro PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse storage volume. Especifique seu PersistentVolumeClaim no campo `claimRef` do PV para outros PVCs não façam bind nele. - +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que alguma outra PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique sua PersistentVolumeClaim no campo `claimRef` do PV para que outras PVCs não façam bind nele. ```yaml apiVersion: v1 @@ -251,11 +200,11 @@ spec: Isso é útil se você deseja utilizar PersistentVolumes que possuem suas `claimPolicy` configuradas para `Retain`, incluindo situações onde você estiver reutilizando um PV existente. -### Expandindo Requisições de Persistent Volumes +### Expandindo Requisições de Volumes Persistentes {{< feature-state for_k8s_version="v1.11" state="beta" >}} -Agora o suporte para expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: +Agora, o suporte à expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: * gcePersistentDisk * awsElasticBlockStore @@ -268,7 +217,7 @@ Agora o suporte para expansão de PersistentVolumeClaims (PVCs) já é habilitad * FlexVolumes * {{< glossary_tooltip text="CSI" term_id="csi" >}} -Você só pode expandir um PVC se o campo do storage class `allowVolumeExpansion` é true. +Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é _true_. ``` yaml apiVersion: storage.k8s.io/v1 @@ -284,7 +233,7 @@ parameters: allowVolumeExpansion: true ``` -Para solicitar um volume maior para um PVC, edite o PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invès disso, um volume existente é redimensionado. +Para solicitar um volume maior para uma PVC, edite a PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invés disso, um volume existente é redimensionado. #### Expansão de volume CSI @@ -296,22 +245,21 @@ O suporte à expansão de volumes CSI é habilitada por padrão, porém é neces Só podem ser redimensionados os volumes que contém os seguintes sistemas de arquivo: XFS, Ext3 ou Ext4. -Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando PersistentVolumeClaim no modo `ReadWrite`. Expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo suporta expansão online. +Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando a PersistentVolumeClaim no modo `ReadWrite`. A expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo tenha suporte para expansão a quente. -FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. -O FlexVolume pode ser redimensionado na reinicialização do Pod. +FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. O FlexVolume pode ser redimensionado na reinicialização do Pod. -#### Redimensionamento de um PersistentVolumeClaim em uso +#### Redimensionamento de uma PersistentVolumeClaim em uso {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -Expansão de PVCs em uso está disponível como beta desde Kubernetes 1.15, e como alpha desde 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. +A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. {{< /note >}} -Neste caso você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por um PVC existente. +Neste caso, você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por uma PVC existente. Automaticamente, qualquer PVC em uso fica disponível para o Pod assim que o sistema de arquivo for expandido. -Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize o PVC antes que a expansão seja completada. +Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize a PVC antes que a expansão seja completada. Da mesma forma que outros tipos de volumes - volumes FlexVolume também podem ser expandidos quando estiverem em uso por um Pod. @@ -320,24 +268,20 @@ Redimensionamento de FlexVolume somente é possível quando o respectivo driver {{< /note >}} {{< note >}} -Expandir volumes EBS é uma operação que toma muito tempo. Além disso, é possível fazer uma modificação por volume a cada 6 horas. +Expandir volumes do tipo EBS é uma operação que toma muito tempo. Além disso, só é possível fazer uma modificação por volume a cada 6 horas. {{< /note >}} #### Recuperação em caso de falha na expansão de volumes +Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado da Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. -Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. - -Se a expansão do respectivo storage falhar, o administrador do cluster pode recuperar manualmente o estado do Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. - - -1. Marque o PersistentVolume(PV) que está atrelado ao PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. -2. Delete o PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando o PVC for recriado. -3. Delete a entrada `claimRef` da especificação do PV para que um PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. -4. Recrie o PVC com um tamanho menor que o PV e configure o campo `volumeName` do PCV com o nome do PV. Isso deve fazer o bind de um novo PVC a um PV existente. +1. Marque o PersistentVolume(PV) que estiver atrelado à PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. +2. Delete a PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando a PVC for recriada. +3. Delete a entrada `claimRef` da especificação do PV para que uma PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. +4. Recrie a PVC com um tamanho menor que o PV e configure o campo `volumeName` da PCV com o nome do PV. Isso deve fazer o bind de uma nova PVC a um PV existente. 5. Não esqueça de restaurar a política de recuperação do PV. -## Tipos de volumes persistentes. +## Tipos de volumes persistentes Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernetes suporta os plugins abaixo: @@ -354,7 +298,7 @@ Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernet * [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume * [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume - (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere utilizari volume `local`.) + (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere a utilização de volume `local`.) * [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage * [`local`](/docs/concepts/storage/volumes/#local) - storage local montados nos nós. * [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage @@ -370,7 +314,7 @@ Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernet ## Volumes Persistentes -Cada PV contém uma spec e um status, que é a espeficiação e o status do volume. O nome de PersistentVolume deve ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)válido. +Cada PV contém uma `spec` e um status, que é a espeficiação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. ```yaml apiVersion: v1 @@ -383,7 +327,7 @@ spec: volumeMode: Filesystem accessModes: - ReadWriteOnce - persistentVolumeReclaimPolicy: Reciclar + persistentVolumeReclaimPolicy: Retain storageClassName: slow mountOptions: - hard @@ -394,21 +338,15 @@ spec: ``` {{< note >}} -Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar /sbin/mount.nfs é necessário para suportar a montagem dos sistemas de arquivos NFS. +Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar _/sbin/mount.nfs_ é necessário para suportar a montagem dos sistemas de arquivos NFS. {{< /note >}} ### Capacidade - -Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. +Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja o [Modelo de Recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) do Kubernetes para entender as unidades aceitas pelo atributo `capacity`. Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. -Geralmente, um PV terá uma capacidade de storage específica. Isso é configurado usando o atributo `capacity` do PV. Veja Kubernetes [Resource Model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) para entender as unidades aceitas pelo atributo `capacity`. - -Atualmente, o tamanho do storage é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. - - ### Modo do Volume {{< feature-state for_k8s_version="v1.18" state="stable" >}} @@ -418,9 +356,9 @@ O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Bl `volumeMode` é um parâmetro opicional da API. `Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. -Um volume com `volumeMode: Filesystem` é *mounted* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. +Um volume com `volumeMode: Filesystem` é *montado* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. -Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma cama de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Raw Block Volume Support](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. +Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma camada de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Suporte a Volume de Bloco Bruto](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. ### Modos de Acesso @@ -428,9 +366,9 @@ Um PersistentVolume pode ser montado num host das mais variadas formas suportada Os modos de acesso são: -* ReadWriteOnce -- o volume pode ser montado como read-write por um nó único -* ReadOnlyMany -- o volume pode ser montado como ready-only por vários nós -* ReadWriteMany -- o volume pode ser montado como read-write por vários nós +* ReadWriteOnce -- o volume pode ser montado como leitura-escrita por um nó único +* ReadOnlyMany -- o volume pode ser montado como somente-leitura por vários nós +* ReadWriteMany -- o volume pode ser montado como leitura-escrita por vários nós Na linha de comando, os modos de acesso ficam abreviados: @@ -459,37 +397,33 @@ Na linha de comando, os modos de acesso ficam abreviados: | Quobyte | ✓ | ✓ | ✓ | | NFS | ✓ | ✓ | ✓ | | RBD | ✓ | ✓ | - | -| VsphereVolume | ✓ | - | - (funcionam quando os Pods são do tipo collocated) | +| VsphereVolume | ✓ | - | (funcionam quando os Pods são do tipo collocated) | | PortworxVolume | ✓ | - | ✓ | | ScaleIO | ✓ | ✓ | - | | StorageOS | ✓ | - | - | ### Classe -Um PV pode ter uma classe, que é especificada na configuração do atribute `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possuí nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. +Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. -No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. +No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ### Política de Retenção Atuamente as políticas de retenção são: -* Retenção -- recuperação manual -* Reciclar -- limpeza básica (`rm -rf /thevolume/*`) +* Retain -- recuperação manual +* Recycle -- limpeza básica (`rm -rf /thevolume/*`) +* Delete -- o volume de armazenamento associado, como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder é deletado -* Delete -- armazenamento associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted - -* Delete -- storage associado como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder volume is deleted - - -Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk, and Cinder suportam delete. +Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk e Cinder suportam delete. ### Opções de Montagem -Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Persistent Volume é montado num nó. +Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Volume Persistente é montado num nó. {{< note >}} -Nem todos os tipos de Persistent Volume suportam opções de montagem. +Nem todos os tipos de Volume Persistente suportam opções de montagem. {{< /note >}} Seguem os tipos de volumes que suportam opções de montagem. @@ -508,14 +442,14 @@ Seguem os tipos de volumes que suportam opções de montagem. * VsphereVolume * iSCSI -Não há validação em relação às opções de montagem. A montagem irá falhar se houver uma opção de montagem inválida. +Não há validação em relação às opções de montagem. A montagem irá falhar se houver alguma opção inválida. -No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. +No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ### Afinidade de Nó {{< note >}} -Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes do tipo bloco: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). {{< /note >}} Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. @@ -530,12 +464,11 @@ Um volume sempre estará em dos seguintes estados: * Failed -- o volume fracassou na sua recuperação automática -A CLI mostrará o nome do PV que foi atrelado ao PVC -The CLI will show the name of the PVC bound to the PV. +A CLI mostrará o nome do PV que foi atrelado à PVC ## PersistentVolumeClaims -Cada PVC contém uma spec e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. +Cada PVC contém uma `spec` e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. ```yaml apiVersion: v1 @@ -559,12 +492,8 @@ spec: ### Modos de Acesso - As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. -As requisições usam as mesmas convenções que os volumes quando eles solicitam um storage com um modo de acesso específico. - - ### Modos de Volume As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. @@ -572,16 +501,13 @@ As requisições usam as mesmas convenções que os volumes quando eles indicam ### Recursos -Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) vale para volumes e requisições. -Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por storage. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) valem para volumes e requisições. +### Seletor +Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que safistaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: -### Selector - -Requisições podem especifiar um [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam labels que safistaçam os critérios do selector podem ser atreladas à requisição. O selector podem conter dois campos: - -* `matchLabels` - o volume deve ter uma label com esse valor +* `matchLabels` - o volume deve ter um rótulo com esse valor * `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - todos eles juntos devem ser atendidos. @@ -590,28 +516,24 @@ Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - to Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. -Os PVCs não precisam necessariamente solicitar uma classe. Um PVC com seu `storageClassName` configurado como `""` sempre vai solicitar um PV sem classe, dessa forma ele sempre será atrelado a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Um PVC sem `storageClassName` não é a mesma coisa e será tratado pelo cluster de forma diferente, porém isso vai depender se o [`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) estiver habilitado. +As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com seu `storageClassName` configurada como `""` sempre vai solicitar um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso vai depender se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. -* Se o admission plugin estiver habilitado, o administrador pode especificar o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` podem ser atrelados somente a PVs que atendam a essa padrão. A especificação de um StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto do StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de um PVC como se o admission plugin estivesse desabilitado. Se mais de um valor padrão for especificado, o admission plugin proíbe a criação de todos os PVCs. -* Se o admission plugin estiver desabilitado, não haverá nenhuma notação para o StorageClass padrão. Todos os PVCs que não tiverem `storageClassName` poderão ser atrelados somente aos PVs que não possuem classe.Neste caso, os PVCs que não tiverem `storageClassName` são tratados da mesma forma como os PVCs que possuem seus `storageClassName` configurados como `""`. +* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a essa padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissã proíbe a criação de todas as PVCs. +* Se o plugin de admissão estiver desabilitado, não haverá nenhuma notação para a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` poderão ser atreladas somente aos PVs que não possuem classe. Neste caso, as PVCs que não tiverem `storageClassName` são tratadas da mesma forma como as PVCs que possuem suas `storageClassName` configuradas como `""`. -Dependendo do modo de instalação, um StorageClass padrão pode ser deployed num cluster Kubernetes durante a instalação pelo addon manager. +Dependendo do modo de instalação, uma StorageClass padrão pode ser implantada num cluster Kubernetes durante a instalação pelo addon manager. -Quando um PVC especifica um `selector` para solicitar um StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com a label requisistada pode ser atrelado ao PVC. +Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisistado pode ser atrelado à PVC. {{< note >}} -Atualmente, um PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. +Atualmente, uma PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. {{< /note >}} -No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atribute `storageClassName` Essa notação ainda funciona; contudo, ela será totalmente depreciada numa futura release do Kubernetes. +No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atributo `storageClassName` Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ## Requisições como Volumes - -Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. - -Os Pods podem ter acesso ao storage utilizando a requisição como um volume. Para isso a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. - +Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso, a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. ```yaml apiVersion: v1 @@ -633,21 +555,17 @@ spec: ### Sobre Namespaces -Os binds dos PersistentVolumes são exclusivos e desde que PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. +Os binds dos PersistentVolumes são exclusivos e, desde que as PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. ### PersistentVolumes do tipo `hostPath` -Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). -A `hostPath` PersistentVolume uses a file or directory on the Node to emulate network-attached storage. Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). - -## Raw Block Volume Support +## Suporte a Volume de Bloco Bruto {{< feature-state for_k8s_version="v1.18" state="stable" >}} - -Os plugins de volume abaixo suportam raw block volumes, incluindo provisionamento dinâmico onde for possível: -applicable: +Os plugins de volume abaixo suportam volumes de bloco bruto, incluindo provisionamento dinâmico onde for aplicável: * AWSElasticBlockStore * AzureDisk @@ -660,8 +578,7 @@ applicable: * RBD (Ceph Block Device) * VsphereVolume - -### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume} +### Utilização de PersistentVolume com Volume de Bloco Bruto {#persistent-volume-using-a-raw-block-volume} ```yaml apiVersion: v1 @@ -680,8 +597,8 @@ spec: lun: 0 readOnly: false ``` - -### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume} + +### Requisição de PersistentVolumeClaim com Volume de Bloco Bruto {#persistent-volume-claim-requesting-a-raw-block-volume} ```yaml apiVersion: v1 @@ -697,8 +614,7 @@ spec: storage: 10Gi ``` - -### Pod specification adding Raw Block Device path in container +### Especificação de Pod com Dipositivo de Bloco Bruto no contêiner ```yaml apiVersion: v1 @@ -721,16 +637,14 @@ spec: ``` {{< note >}} - -Quando adicionar a raw block device para um Pod, você especifica o caminho do dispositivo no container ao invés de um mount path +Quando adicionar um dispositivo de bloco bruto num Pod, você especifica o caminho do dispositivo no contêiner ao invés de um ponto de montagem. {{< /note >}} ### Bind de Volumes de Bloco -Se um usuário solicita um raw block volume através do campo `volumeMode` na spec do PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não vão considerar esse modo como parte da spec. - -A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um raw block device. A tabela indica se o volume será ou não atrelado com base nas combinações: -Matrix de bind de volume para provisionamento estático de volumes: +Se um usuário solicita um volume de bloco bruto através do campo `volumeMode` na `spec` da PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não consideravam esse modo como parte da `spec`. +A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: +Matriz de bind de volume para provisionamento estático de volumes: | PV volumeMode | PVC volumeMode | Result | | --------------|:---------------:| ----------------:| @@ -745,18 +659,17 @@ Matrix de bind de volume para provisionamento estático de volumes: | Filesystem | unspecified | BIND | {{< note >}} - -O provisionamento estático de volumes é suportado somente na versão alpha. Administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com raw block devices. +O provisionamento estático de volumes é suportado somente na versão alpha. Os administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com dispositivos de bloco bruto. {{< /note >}} ## Snapshot de Volume e Restauração de Volume a partir de um Snapshot {{< feature-state for_k8s_version="v1.20" state="stable" >}} -O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Volume Snapshots](/docs/concepts/storage/volume-snapshots/) para mais detalhes. -Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). +O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Snapshot de Volume](/docs/concepts/storage/volume-snapshots/) para mais detalhes. +Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Perguntas Frequentes sobre Plugins de Volume](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). -### Criar um PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} +### Criar uma PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} ```yaml apiVersion: v1 @@ -778,9 +691,9 @@ spec: ## Clonagem de Volume -[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) only available for CSI volume plugins. +A [Clonagem de Volume](/docs/concepts/storage/volume-pvc-datasource/) é possível somente com plugins de volume CSI. -### Criação de PersistentVolumeClaim a partir de um PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} +### Criação de PersistentVolumeClaim a partir de uma PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} ```yaml apiVersion: v1 @@ -802,30 +715,21 @@ spec: ## Boas Práticas de Configuração -Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize a estrutura abaixo: +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize o padrão abaixo: -Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de storage persistente, recomendamos que utilize a estrutura abaixo: - - -- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntanemte com Deployments, ConfigMaps, etc). +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntamente com Deployments, ConfigMaps, etc). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. - the config may not have permission to create PersistentVolumes. - Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instaciar o template. - - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de armazenamento correta se o cluster tiver o StorageClasses habilitado pelo administrador. - - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de armazenamento (que no caso, o usuário não pode fazer deploy solicitando PVCs). -- Dê ao usuário a opção dele informar o nome de uma classe de storage quando instaciar o template. - - Se o usuário informar o nome de uma classe de storage, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que o PVC encontre a classe de storage correta se o cluster tiver o StorageClasses habilitado pelo administrador. - - Se o usuário não informar o nome da classe de storage, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (null). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Em muitos ambientes, o StorageClass padrão já instalado no cluster, ou então, os administradores podem criar seus StorageClass padrão. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atrelados, pois isso talvez indique que o cluster não tem provisionamento dinâmico (que no caso, o usuário deveria criar um PV que satisfaça os critérios do PVC) ou cluster não tem um sistema de storage (que no caso, o usuário não pode fazer deploy solicitando PVCs). - + - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que a PVC encontre a classe de armazenamento correta se o cluster tiver a StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (vazio). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Muitos ambientes de cluster já possuem uma StorageClass padrão, ou então os administradores podem criar suas StorageClass de acordo com seus critérios. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). ## {{% heading "whatsnext" %}} * Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). -* Leia a [documentação sobre plajemamento de Storage Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). +* Leia a [documentação sobre plajemamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). ### Referência From 172de26c54ed9b53f7dff12b738d6e3c8decd17b Mon Sep 17 00:00:00 2001 From: Emanuel Haine Date: Sun, 7 Mar 2021 17:13:46 -0300 Subject: [PATCH 0051/1733] Miswritten corrections --- .../concepts/storage/persistent-volumes.md | 70 +++++++++---------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/content/pt/docs/concepts/storage/persistent-volumes.md b/content/pt/docs/concepts/storage/persistent-volumes.md index 7236c4c56d..8e952c607a 100644 --- a/content/pt/docs/concepts/storage/persistent-volumes.md +++ b/content/pt/docs/concepts/storage/persistent-volumes.md @@ -24,13 +24,13 @@ Esse documento descreve o estado atual dos _volumes persistentes_ no Kubernetes. ## Introdução -O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsitema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. +O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsistema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzidmos duas novas APIs: PersistentVolume e PersistentVolumeClaim. Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). -Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como performance, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que sejam diferentes em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. +Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como desempenho, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que difiram em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). @@ -40,7 +40,7 @@ PVs são recursos dentro um cluster. PVCs são requisições para esses recursos ### Provisionamento -Existem duas formas de provisionar um PV: staticamente ou dinamicamente. +Existem duas formas de provisionar um PV: estaticamente ou dinamicamente. #### Estático @@ -48,15 +48,15 @@ O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem #### Dinâmico -Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrator, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrador, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. -Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para maiores informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para mais informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). ### Binding -Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele tinha solicitado, porém o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um pra um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele havia solicitado, porém, o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um para um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. -As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100GB não vai ocorrer num cluster que foi provisionado com vários PVs de 50GB. O bind ocorrerá somente no momento em que um PV de 100GB for adicionado. +As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100 GB não ocorrerá num cluster que foi provisionado com vários PVs de 50 GB. O bind ocorrerá somente no momento em que um PV de 100 GB for adicionado. ### Utilização @@ -72,9 +72,9 @@ O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso Uma PVC está sendo utilizada por um Pod quando existe um Pod que está usando essa PVC. {{< /note >}} -Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um admin deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. +Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um administrador deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. -Você pode ver que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: +Note que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: ```shell kubectl describe pvc hostpath @@ -90,7 +90,7 @@ Finalizers: [kubernetes.io/pvc-protection] ... ``` -Você pode ver que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: +Note que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: ```shell kubectl describe pv task-pv-volume @@ -114,25 +114,25 @@ Events: ### Recuperação -Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que por sua vez permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. +Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que, permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. #### Retenção A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manuamente recuperar o volume executando os seguintes passos: -1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk, or Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk ou Cinder volume) ainda continuará existindo após o PV ser deletado. 1. Limpar os dados de forma manual no armazenamento associado. 1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. #### Deletar -Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de renteção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de retenção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). #### Reciclar {{< warning >}} -A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionametno dinâmico. +A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionamento dinâmico. {{< /warning >}} Em caso do volume plugin ter suporte a essa operação, a política de retenção `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisição. @@ -165,7 +165,7 @@ Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é ### Reservando um PersistentVolume -A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específco, é preciso fazer o pré-bind deles. +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específico, é preciso fazer o pré-bind deles. Especificando um PersistentVolume na PersistentVolumeClaim, você declara um bind entre uma PVC e um PV específico. O bind ocorrerá se o PersistentVolume existir e não estiver reservado por uma PersistentVolumeClaims através do seu campo `claimRef`. @@ -217,7 +217,7 @@ Agora, o suporte à expansão de PersistentVolumeClaims (PVCs) já é habilitado * FlexVolumes * {{< glossary_tooltip text="CSI" term_id="csi" >}} -Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é _true_. +Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é `true`. ``` yaml apiVersion: storage.k8s.io/v1 @@ -254,7 +254,7 @@ FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é confi {{< feature-state for_k8s_version="v1.15" state="beta" >}} {{< note >}} -A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para maiores informações. +A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para mais informações. {{< /note >}} Neste caso, você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por uma PVC existente. @@ -314,7 +314,7 @@ Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernet ## Volumes Persistentes -Cada PV contém uma `spec` e um status, que é a espeficiação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. +Cada PV contém uma `spec` e um status, que é a especificação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. ```yaml apiVersion: v1 @@ -353,7 +353,7 @@ Atualmente, o tamanho do armazenamento é o único recurso que pode ser configur O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Block`. -`volumeMode` é um parâmetro opicional da API. +`volumeMode` é um parâmetro opcional da API. `Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. Um volume com `volumeMode: Filesystem` é *montado* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. @@ -376,7 +376,7 @@ Na linha de comando, os modos de acesso ficam abreviados: * ROX - ReadOnlyMany * RWX - ReadWriteMany -> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não ao mesmo tempo. +> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não simultaneamente. | Plugin de Volume | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| @@ -404,13 +404,13 @@ Na linha de comando, os modos de acesso ficam abreviados: ### Classe -Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. +Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requisições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. ### Política de Retenção -Atuamente as políticas de retenção são: +Atualmente as políticas de retenção são: * Retain -- recuperação manual * Recycle -- limpeza básica (`rm -rf /thevolume/*`) @@ -449,7 +449,7 @@ No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no l ### Afinidade de Nó {{< note >}} -Para a maioria dos tipos de volume, a configurção desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +Para a maioria dos tipos de volume, a configuração desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). {{< /note >}} Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. @@ -460,7 +460,7 @@ Um volume sempre estará em dos seguintes estados: * Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição * Bound -- um volume atrelado a uma requisição -* Released -- a requisião foi deletada, mas o curso ainda não foi recuperado pelo cluster +* Released -- a requisição foi deletada, mas o curso ainda não foi recuperado pelo cluster * Failed -- o volume fracassou na sua recuperação automática @@ -505,7 +505,7 @@ Assim como Pods, as requisições podem solicitar quantidades específicas de re ### Seletor -Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que safistaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: +Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que satisfaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: * `matchLabels` - o volume deve ter um rótulo com esse valor * `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. @@ -516,14 +516,14 @@ Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - to Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. -As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com seu `storageClassName` configurada como `""` sempre vai solicitar um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação ou seja igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso vai depender se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. +As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com sua `storageClassName` configurada como `""` sempre solicitará um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação, ou seja, igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso dependerá se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. -* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a essa padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissã proíbe a criação de todas as PVCs. +* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a esse padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissão proíbe a criação de todas as PVCs. * Se o plugin de admissão estiver desabilitado, não haverá nenhuma notação para a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` poderão ser atreladas somente aos PVs que não possuem classe. Neste caso, as PVCs que não tiverem `storageClassName` são tratadas da mesma forma como as PVCs que possuem suas `storageClassName` configuradas como `""`. Dependendo do modo de instalação, uma StorageClass padrão pode ser implantada num cluster Kubernetes durante a instalação pelo addon manager. -Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisistado pode ser atrelado à PVC. +Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisitado pode ser atrelado à PVC. {{< note >}} Atualmente, uma PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. @@ -559,7 +559,7 @@ Os binds dos PersistentVolumes são exclusivos e, desde que as PersistentVolumeC ### PersistentVolumes do tipo `hostPath` -Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja um [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). ## Suporte a Volume de Bloco Bruto @@ -614,7 +614,7 @@ spec: storage: 10Gi ``` -### Especificação de Pod com Dipositivo de Bloco Bruto no contêiner +### Especificação de Pod com Dispositivo de Bloco Bruto no contêiner ```yaml apiVersion: v1 @@ -643,7 +643,7 @@ Quando adicionar um dispositivo de bloco bruto num Pod, você especifica o camin ### Bind de Volumes de Bloco Se um usuário solicita um volume de bloco bruto através do campo `volumeMode` na `spec` da PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não consideravam esse modo como parte da `spec`. -A tabela abaixo mostra as possíveis combinações que um usuário e um admin pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: +A tabela abaixo mostra as possíveis combinações que um usuário e um administrador pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: Matriz de bind de volume para provisionamento estático de volumes: | PV volumeMode | PVC volumeMode | Result | @@ -717,19 +717,19 @@ spec: Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize o padrão abaixo: -- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (juntamente com Deployments, ConfigMaps, etc). +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (com Deployments, ConfigMaps, etc.). - Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. -- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instaciar o template. +- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instanciar o template. - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que a PVC encontre a classe de armazenamento correta se o cluster tiver a StorageClasses habilitado pelo administrador. - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (vazio). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Muitos ambientes de cluster já possuem uma StorageClass padrão, ou então os administradores podem criar suas StorageClass de acordo com seus critérios. -- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois, isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). ## {{% heading "whatsnext" %}} * Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). -* Leia a [documentação sobre plajemamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). +* Leia a [documentação sobre planejamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). ### Referência From 07c5dbcbca062313c3603c396470269d97be20dd Mon Sep 17 00:00:00 2001 From: Abdullah Gharaibeh Date: Wed, 3 Mar 2021 12:12:42 -0500 Subject: [PATCH 0052/1733] Docs for pod affinity namespace selector and pod affinity corss-namespace quota scope. --- .../docs/concepts/policy/resource-quotas.md | 58 +++++++++++++++++++ .../scheduling-eviction/assign-pod-node.md | 12 ++++ .../feature-gates.md | 3 + 3 files changed, 73 insertions(+) diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index bc5eca8754..034458b8e9 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -189,6 +189,7 @@ Resources specified on the quota outside of the allowed set results in a validat | `BestEffort` | Match pods that have best effort quality of service. | | `NotBestEffort` | Match pods that do not have best effort quality of service. | | `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). | +| `CrossNamespacePodAffinity` | Match pods that have cross-namespace pod [(anti)affinity terms](/docs/concepts/scheduling-eviction/assign-pod-node). | The `BestEffort` scope restricts a quota to tracking the following resource: @@ -429,6 +430,63 @@ memory 0 20Gi pods 0 10 ``` +### Cross-namespace Pod Affinity Quota + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Operators can use `CrossNamespacePodAffinity` quota scope to limit which namespaces are allowed to +have pods with affinity terms that cross namespaces. Specifically, it controls which pods are allowed +to set `namespaces` or `namespaceSelector` fields in pod affinity terms. + +Preventing users from using cross-namespace affinity terms might be desired since a pod +with anti-affinity constraints can block pods from all other namespaces +from getting scheduled in a failure domain. + +Using this scope operators can prevent certain namespaces (`foo-ns` in the example below) +from having pods that use cross-namespace pod affinity by creating a resource quota object in +that namespace with `CrossNamespaceAffinity` scope and hard limit of 0: + +```yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: disable-cross-namespace-affinity + namespace: foo-ns +spec: + hard: + pods: "0" + scopeSelector: + matchExpressions: + - scopeName: CrossNamespaceAffinity +``` + +If operators want to disallow using `namespaces` and `namespaceSelector` by default, and +only allow it for specific namespaces, they could configure `CrossNamespaceAffinity` +as a limited resource by setting the kube-apiserver flag --admission-control-config-file +to the path of the following configuration file: + +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: apiserver.config.k8s.io/v1 + kind: ResourceQuotaConfiguration + limitedResources: + - resource: pods + matchScopes: + - scopeName: CrossNamespaceAffinity +``` + +With the above configuration, pods can use `namespaces` and `namespaceSelector` in pod affinity only +if the namespace where they are created have a resource quota object with +`CrossNamespaceAffinity` scope and a hard limit greater than or equal to the number of pods using those fields. + +This feature is alpha and disabled by default. You can enable it by setting the +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler. + ## Requests compared to Limits {#requests-vs-limits} When allocating compute resources, each container may specify a request and a limit value for either CPU or memory. diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index b6b2bd79a8..8b13ed3b45 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -271,6 +271,18 @@ If omitted or empty, it defaults to the namespace of the pod where the affinity/ All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity must be satisfied for the pod to be scheduled onto a node. +#### Namespace selector +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces. +The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field. +Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and +null `namespaceSelector` means "this pod's namespace". + +This feature is alpha and disabled by default. You can enable it by setting the +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler. + #### More Practical Use-cases Interpod Affinity and AntiAffinity can be even more useful when they are used with higher diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 2e9db5fce0..82224cf6c6 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -139,6 +139,7 @@ different Kubernetes components. | `NonPreemptingPriority` | `true` | Beta | 1.19 | | | `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | | `PodDisruptionBudget` | `true` | Beta | 1.5 | | +| `PodAffinityNamespaceSelector` | `false` | Alpha | 1.21 | | | `PodOverhead` | `false` | Alpha | 1.16 | 1.17 | | `PodOverhead` | `true` | Beta | 1.18 | | | `ProcMountType` | `false` | Alpha | 1.12 | | @@ -668,6 +669,8 @@ Each feature gate is designed for enabling/disabling a specific feature: - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods. Pod affinity has to be specified if requesting a `local` volume. - `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature. +- `PodAffinityNamespaceSelector`: Enable the [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector) + and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) quota scope features. - `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/) feature to account for pod overheads. - `PodPriority`: Enable the descheduling and preemption of Pods based on their From 5fcc8b29614f7f72b563a61d9d75dac70c7e5c75 Mon Sep 17 00:00:00 2001 From: Sandeep Rajan Date: Thu, 4 Mar 2021 12:06:09 -0500 Subject: [PATCH 0053/1733] remove mentions of kube-dns in kubeadm docs --- .../kubeadm/implementation-details.md | 8 +++--- .../setup-tools/kubeadm/kubeadm-config.md | 4 --- .../setup-tools/kubeadm/kubeadm-init-phase.md | 19 -------------- .../setup-tools/kubeadm/kubeadm-init.md | 4 +-- .../setup-tools/kubeadm/kubeadm-upgrade.md | 2 -- .../tools/kubeadm/troubleshooting-kubeadm.md | 2 +- .../docs/tasks/administer-cluster/coredns.md | 26 +++---------------- .../dns-custom-nameservers.md | 14 ++-------- .../kubeadm/kubeadm-upgrade.md | 2 +- 9 files changed, 12 insertions(+), 69 deletions(-) diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 5a321ec670..026e24f2ed 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -436,12 +436,12 @@ A ServiceAccount for `kube-proxy` is created in the `kube-system` namespace; the #### DNS -- In Kubernetes version 1.18 kube-dns usage with kubeadm is deprecated and will be removed in a future release +- In Kubernetes version 1.21 kube-dns usage with kubeadm has been removed - The CoreDNS service is named `kube-dns`. This is done to prevent any interruption -in service when the user is switching the cluster DNS from kube-dns to CoreDNS or vice-versa +in service when the user is switching the cluster DNS from kube-dns to CoreDNS the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) -- A ServiceAccount for CoreDNS/kube-dns is created in the `kube-system` namespace. -- The `kube-dns` ServiceAccount is bound to the privileges in the `system:kube-dns` ClusterRole +- A ServiceAccount for CoreDNS is created in the `kube-system` namespace. +- The `coredns` ServiceAccount is bound to the privileges in the `system:coredns` ClusterRole ## kubeadm join phases internal design diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md index 23dff658e9..93f89c594b 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md @@ -20,10 +20,6 @@ For more information navigate to [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). -In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image -the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) -has to be used. - ## kubeadm config view {#cmd-config-view} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md index 21ab7a863d..2b6939bac6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md @@ -143,25 +143,6 @@ install them selectively. {{< tab name="kube-proxy" include="generated/kubeadm_init_phase_addon_kube-proxy.md" />}} {{< /tabs >}} -To use kube-dns instead of CoreDNS you have to pass a configuration file: - -```bash -# for installing a DNS addon only -kubeadm init phase addon coredns --config=someconfig.yaml -``` - -The file has to contain a [`dns`](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#DNS) field in[`ClusterConfiguration`](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration) -and also a type for the addon - `kube-dns` (default value is `CoreDNS`). - -```yaml -apiVersion: kubeadm.k8s.io/v1beta2 -kind: ClusterConfiguration -dns: - type: "kube-dns" -``` - -Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will be removed in a future release. - For more details on each field in the `v1beta2` configuration you can navigate to our [API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index 3d4b977102..eb5fb20943 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -66,12 +66,10 @@ following steps: 1. Installs a DNS server (CoreDNS) and the kube-proxy addon components via the API server. In Kubernetes version 1.11 and later CoreDNS is the default DNS server. - To install kube-dns instead of CoreDNS, the DNS addon has to be configured in the kubeadm `ClusterConfiguration`. - For more information about the configuration see the section `Using kubeadm init with a configuration file` below. Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed. {{< warning >}} - kube-dns usage with kubeadm is deprecated as of v1.18 and will be removed in a future release. + kube-dns usage with kubeadm is deprecated as of v1.18 and is removed in v1.21. {{< /warning >}} ### Using init phases with kubeadm {#init-phases} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md index 5796e7aec7..6a2c5f782f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -20,8 +20,6 @@ For older versions of kubeadm, please refer to older documentation sets of the K You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests. -To use kube-dns with upgrades in Kubernetes v1.13.0 and later please follow [this guide](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon). - In Kubernetes v1.15.0 and later, `kubeadm upgrade apply` and `kubeadm upgrade node` will also automatically renew the kubeadm managed certificates on this node, including those stored in kubeconfig files. To opt-out, it is possible to pass the flag `--certificate-renewal=false`. For more details about certificate diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 28ef3d3038..aff03fb1ab 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -149,7 +149,7 @@ Right after `kubeadm init` there should not be any pods in these states. MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state. The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files. -## `coredns` (or `kube-dns`) is stuck in the `Pending` state +## `coredns` is stuck in the `Pending` state This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin should [install the pod network add-on](/docs/concepts/cluster-administration/addons/) diff --git a/content/en/docs/tasks/administer-cluster/coredns.md b/content/en/docs/tasks/administer-cluster/coredns.md index 32d4f7d7ec..54163058c8 100644 --- a/content/en/docs/tasks/administer-cluster/coredns.md +++ b/content/en/docs/tasks/administer-cluster/coredns.md @@ -36,7 +36,7 @@ For manual deployment or replacement of kube-dns, see the documentation at the In Kubernetes version 1.10 and later, you can also move to CoreDNS when you use `kubeadm` to upgrade a cluster that is using `kube-dns`. In this case, `kubeadm` will generate the CoreDNS configuration -("Corefile") based upon the `kube-dns` ConfigMap, preserving configurations for federation, +("Corefile") based upon the `kube-dns` ConfigMap, preserving configurations for stub domains, and upstream name server. If you are moving from kube-dns to CoreDNS, make sure to set the `CoreDNS` feature gate to `true` @@ -46,8 +46,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true ``` In Kubernetes version 1.13 and later the `CoreDNS` feature gate is removed and CoreDNS -is used by default. Follow the guide outlined [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon) if you want -your upgraded cluster to use kube-dns. +is used by default. In versions prior to 1.11 the Corefile will be **overwritten** by the one created during upgrade. **You should save your existing ConfigMap if you have customized it.** You may re-apply your @@ -56,26 +55,7 @@ customizations after the new ConfigMap is up and running. If you are running CoreDNS in Kubernetes version 1.11 and later, during upgrade, your existing Corefile will be retained. - -### Installing kube-dns instead of CoreDNS with kubeadm - -{{< note >}} -In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA) -and is installed by default. -{{< /note >}} - -{{< warning >}} -In Kubernetes 1.18, kube-dns usage with kubeadm has been deprecated and will be removed in a future version. -{{< /warning >}} - -To install kube-dns on versions prior to 1.13, set the `CoreDNS` feature gate -value to `false`: - -``` -kubeadm init --feature-gates=CoreDNS=false -``` - -For versions 1.13 and later, follow the guide outlined [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon). +In Kubernetes version 1.21, support for `kube-dns` is removed from kubeadm. ## Upgrading CoreDNS diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md index 06de85b305..308b066651 100644 --- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -34,7 +34,7 @@ As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dn originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS. {{< note >}} -Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field. +The CoreDNS Service is named `kube-dns` in the `metadata.name` field. This is so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. Using a Service named `kube-dns` abstracts away the implementation detail of which DNS provider is running behind that common name. {{< /note >}} @@ -179,17 +179,14 @@ During translation, all FQDN nameservers will be omitted from the CoreDNS config CoreDNS supports the features of kube-dns and more. A ConfigMap created for kube-dns to support `StubDomains`and `upstreamNameservers` translates to the `forward` plugin in CoreDNS. -Similarly, the `Federations` plugin in kube-dns translates to the `federation` plugin in CoreDNS. ### Example -This example ConfigMap for kube-dns specifies federations, stubdomains and upstreamnameservers: +This example ConfigMap for kube-dns specifies stubdomains and upstreamnameservers: ```yaml apiVersion: v1 data: - federations: | - {"foo" : "foo.feddomain.com"} stubDomains: | {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} upstreamNameservers: | @@ -199,13 +196,6 @@ kind: ConfigMap The equivalent configuration in CoreDNS creates a Corefile: -* For federations: -``` -federation cluster.local { - foo foo.feddomain.com -} -``` - * For stubDomains: ```yaml abc.com:53 { diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 5af9d27b82..45466a6b5c 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -328,7 +328,7 @@ and post-upgrade manifest file for a certain component, a backup file for it wil - Makes sure the control plane images are available or available to pull to the machine. - Generates replacements and/or uses user supplied overwrites if component configs require version upgrades. - Upgrades the control plane components or rollbacks if any of them fails to come up. -- Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created. +- Applies the new `CoreDNS` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created. - Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days. `kubeadm upgrade node` does the following on additional control plane nodes: From 3e9a73f7c28d76280c76d74dc3e58213715b99b4 Mon Sep 17 00:00:00 2001 From: Sandeep Rajan Date: Fri, 5 Mar 2021 12:12:27 -0500 Subject: [PATCH 0054/1733] move kube-dns remove statement to the end --- .../reference/setup-tools/kubeadm/implementation-details.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 026e24f2ed..420f6edcac 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -436,13 +436,15 @@ A ServiceAccount for `kube-proxy` is created in the `kube-system` namespace; the #### DNS -- In Kubernetes version 1.21 kube-dns usage with kubeadm has been removed - The CoreDNS service is named `kube-dns`. This is done to prevent any interruption in service when the user is switching the cluster DNS from kube-dns to CoreDNS the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) - A ServiceAccount for CoreDNS is created in the `kube-system` namespace. - The `coredns` ServiceAccount is bound to the privileges in the `system:coredns` ClusterRole +- In Kubernetes version 1.21, support for using `kube-dns` with kubeadm is removed. +You can use CoreDNS with kubeadm even when the related Service is named `kube-dns`. + ## kubeadm join phases internal design Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a sequence of atomic work tasks to perform. From b9576494e91fa4ed8d44f3df23db8031e06ea1f5 Mon Sep 17 00:00:00 2001 From: Sandeep Rajan Date: Mon, 8 Mar 2021 11:56:53 -0500 Subject: [PATCH 0055/1733] nit in tense --- .../reference/setup-tools/kubeadm/implementation-details.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 420f6edcac..670082a3fd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -442,7 +442,7 @@ the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubea - A ServiceAccount for CoreDNS is created in the `kube-system` namespace. - The `coredns` ServiceAccount is bound to the privileges in the `system:coredns` ClusterRole -- In Kubernetes version 1.21, support for using `kube-dns` with kubeadm is removed. +- In Kubernetes version 1.21, support for using `kube-dns` with kubeadm was removed. You can use CoreDNS with kubeadm even when the related Service is named `kube-dns`. ## kubeadm join phases internal design From 2edc0b8e5963862917d3543e48c3aaf36eb81048 Mon Sep 17 00:00:00 2001 From: k-wall Date: Mon, 8 Mar 2021 19:45:15 +0000 Subject: [PATCH 0056/1733] Document behaviour when optionally referenced configmap appears after the pod starts --- .../configure-pod-container/configure-pod-configmap.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index 40987152e8..6432b10c93 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -624,9 +624,15 @@ Like before, all previous files in the `/etc/config/` directory will be deleted. You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. +### Optional References + +A ConfigMap reference may be marked "optional". If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced key is non-existent the path will be absent beneath the mount point. + ### Mounted ConfigMaps are updated automatically -When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of the pod's annotations. +When a mounted ConfigMap is updated, the projected content is eventually updated too. This applies in the case where an optionally referenced ConfigMap comes into existence after a pod has started. + +Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of the pod's annotations. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. From f2464dcc5fdcd666c3594f058647a9c669997008 Mon Sep 17 00:00:00 2001 From: Clayton Coleman Date: Tue, 2 Mar 2021 12:14:39 -0500 Subject: [PATCH 0057/1733] Mark scheduler pod resource metrics as beta They will be part of 1.21 as beta stability. --- .../en/docs/concepts/cluster-administration/system-metrics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/system-metrics.md b/content/en/docs/concepts/cluster-administration/system-metrics.md index 3c7e137ded..073e0c7236 100644 --- a/content/en/docs/concepts/cluster-administration/system-metrics.md +++ b/content/en/docs/concepts/cluster-administration/system-metrics.md @@ -134,7 +134,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ### kube-scheduler metrics -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} The scheduler exposes optional metrics that reports the requested resources and the desired limits of all running pods. These metrics can be used to build capacity planning dashboards, assess current or historical scheduling limits, quickly identify workloads that cannot schedule due to lack of resources, and compare actual usage to the pod's request. From 02b50e1a33c29d8f261707c8ab24c31238a7a4fa Mon Sep 17 00:00:00 2001 From: KobayashiD27 Date: Tue, 9 Mar 2021 10:01:15 +0900 Subject: [PATCH 0058/1733] ja: Make docs/concepts/architecture/controller.md follow v1.19 of the original text --- content/ja/docs/concepts/architecture/controller.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index c2f71c9029..a4477d3fc2 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -50,7 +50,11 @@ Jobとは対照的に、クラスターの外部に変更を加える必要が 外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。 -(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。) +(クラスター内のノードを水平にスケールさせる[コントローラー](https://github.com/kubernetes/autoscaler/)が実際に存在します。) + +ここで重要な点は、コントローラーが目的の状態を実現するために変更を加えてから、現在の状態をクラスターのAPIサーバーに報告することです。 他の制御ループは、その報告されたデータを監視し、独自のアクションを実行できます。 + +サーモスタットの例では、部屋が非常に寒い場合、別のコントローラーが霜防止ヒーターをオンにすることもあります。 Kubernetesクラスターを使用すると、コントロールプレーンは、[Kubernetesを拡張して](/ja/docs/concepts/extend-kubernetes/)実装することにより、IPアドレス管理ツールやストレージサービス、クラウドプロバイダーAPI、およびその他のサービスと間接的に連携します。 ## 目的の状態 vs 現在の状態 {#desired-vs-current} From cf19c5d74b5d86d0630915c5d927fe5329c065be Mon Sep 17 00:00:00 2001 From: CKchen0726 Date: Tue, 9 Mar 2021 12:30:35 +0800 Subject: [PATCH 0059/1733] modify some links in Kustomize Feature List --- .../tasks/manage-kubernetes-objects/kustomization.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index 7c59052ffa..eb6d638603 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -815,14 +815,14 @@ deployment.apps "dev-my-nginx" deleted | commonLabels | map[string]string | labels to add to all resources and selectors | | commonAnnotations | map[string]string | annotations to add to all resources | | resources | []string | each entry in this list must resolve to an existing resource configuration file | -| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99) | Each entry in this list generates a ConfigMap | -| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106) | Each entry in this list generates a Secret | -| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | Modify behaviors of all ConfigMap and Secret generator | +| configMapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/configmapargs.go#L7) | Each entry in this list generates a ConfigMap | +| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/secretargs.go#L7) | Each entry in this list generates a Secret | +| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/generatoroptions.go#L7) | Modify behaviors of all ConfigMap and Secret generator | | bases | []string | Each entry in this list should resolve to a directory containing a kustomization.yaml file | | patchesStrategicMerge | []string | Each entry in this list should resolve a strategic merge patch of a Kubernetes object | -| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8) | Each entry in this list should resolve to a Kubernetes object and a Json Patch | -| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31) | Each entry is to capture text from one resource's field | -| images | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23) | Each entry is to modify the name, tags and/or digest for one image without creating patches | +| patchesJson6902 | [][Patch](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/patch.go#L10) | Each entry in this list should resolve to a Kubernetes object and a Json Patch | +| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L19) | Each entry is to capture text from one resource's field | +| images | [][Image](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/image.go#L8) | Each entry is to modify the name, tags and/or digest for one image without creating patches | | configurations | []string | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) | | crds | []string | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types | From 56fa6f6211475e489e45b0b0110f6c4beed55fa3 Mon Sep 17 00:00:00 2001 From: s-kawamura-w664 Date: Thu, 4 Mar 2021 07:53:35 +0000 Subject: [PATCH 0060/1733] delete some dirty code from several files in ja --- .../concepts/cluster-administration/manage-deployment.md | 2 +- content/ja/docs/concepts/overview/what-is-kubernetes.md | 2 +- content/ja/docs/concepts/policy/resource-quotas.md | 2 +- content/ja/docs/concepts/security/overview.md | 2 +- .../configure-access-multiple-clusters.md | 8 ++++---- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/manage-deployment.md b/content/ja/docs/concepts/cluster-administration/manage-deployment.md index 90f96547d5..cb9c7c0fc3 100644 --- a/content/ja/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ja/docs/concepts/cluster-administration/manage-deployment.md @@ -237,7 +237,7 @@ guestbook-redis-slave-qgazl 1/1 Running 0 3m image: gb-frontend:v3 ``` -そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。 +そして2つの異なるPodのセットを上書きしないようにするため、`track`ラベルに異なる値を持つ(例: `canary`)ようなguestbookフロントエンドの新しいリリースを作成できます。 ```yaml name: frontend-canary diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index 3ca8fa78fe..dab17c9b1b 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -17,7 +17,7 @@ card: Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。 -Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。 +Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロットを意味しています。Googleは2014年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させた[Googleの15年以上の経験](/blog/2015/04/borg-predecessor-to-kubernetes/)と、コミュニティからの最高のアイディアや実践を組み合わせています。 ## 過去を振り返ってみると diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index e7368a8f94..7b00056fcf 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -22,7 +22,7 @@ weight: 10 - 異なる名前空間で異なるチームが存在するとき。現時点ではこれは自主的なものですが、将来的にはACLsを介してリソースクォータの設定を強制するように計画されています。 - 管理者は各名前空間で1つの`ResourceQuota`を作成します。 - ユーザーが名前空間内でリソース(Pod、Serviceなど)を作成し、クォータシステムが`ResourceQuota`によって定義されたハードリソースリミットを超えないことを保証するために、リソースの使用量をトラッキングします。 -- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 +- リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 - `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。 `ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md index b50a4ea1a5..0157b28f78 100644 --- a/content/ja/docs/concepts/security/overview.md +++ b/content/ja/docs/concepts/security/overview.md @@ -77,7 +77,7 @@ Kubernetesを保護する為には２つの懸念事項があります。 ### クラスター内のコンポーネント(アプリケーション) {#cluster-applications} -アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。 +アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。 ワークロードセキュリティに関する懸念事項 | 推奨事項 | diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index b2ebc16d18..d5f6b72296 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -31,9 +31,9 @@ card: ## クラスター、ユーザー、コンテキストを設定する -例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。 +例として、開発用のクラスターが一つ、実験用のクラスターが一つ、計二つのクラスターが存在する場合を考えます。`development`と呼ばれる開発用のクラスター内では、フロントエンドの開発者は`frontend`というnamespace内で、ストレージの開発者は`storage`というnamespace内で作業をします。`scratch`と呼ばれる実験用のクラスター内では、開発者はデフォルトのnamespaceで作業をするか、状況に応じて追加のnamespaceを作成します。開発用のクラスターは証明書を通しての認証を必要とします。実験用のクラスターはユーザーネームとパスワードを通しての認証を必要とします。 -`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください: +`config-exercise`というディレクトリを作成してください。`config-exercise`ディレクトリ内に、以下を含む`config-demo`というファイルを作成してください: ```shell apiVersion: v1 @@ -61,7 +61,7 @@ contexts: 設定ファイルには、クラスター、ユーザー、コンテキストの情報が含まれています。上記の`config-demo`設定ファイルには、二つのクラスター、二人のユーザー、三つのコンテキストの情報が含まれています。 -`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください: +`config-exercise`ディレクトリに移動してください。クラスター情報を設定ファイルに追加するために、以下のコマンドを実行してください: ```shell kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file @@ -89,7 +89,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter ``` -追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。 +追加した情報を確認するために、`config-demo`ファイルを開いてください。`config-demo`ファイルを開く代わりに、`config view`のコマンドを使うこともできます。 ```shell kubectl config --kubeconfig=config-demo view From 58c9ddd24e1518f64036fb5d78ceff2040d79d79 Mon Sep 17 00:00:00 2001 From: pacoxu Date: Wed, 10 Mar 2021 17:09:01 +0800 Subject: [PATCH 0061/1733] Disable CAdvisor Json Metrics completed --- .../command-line-tools-reference/kubelet.md | 7 ------- .../command-line-tools-reference/kubelet.md | 13 ------------- 2 files changed, 20 deletions(-) diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index fdd85997eb..7b28336293 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -298,13 +298,6 @@ kubelet [flags] - - - - - - - diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet.md b/content/zh/docs/reference/command-line-tools-reference/kubelet.md index 317a3a581e..6d7d2e757a 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/zh/docs/reference/command-line-tools-reference/kubelet.md @@ -584,19 +584,6 @@ kubelet 使用此目录来保存所下载的配置，跟踪配置运行状况。 - - - - - - - From 84c530bffb94f9bb284c37cfef02a740908e1228 Mon Sep 17 00:00:00 2001 From: shimodatkh Date: Wed, 10 Mar 2021 11:28:32 +0000 Subject: [PATCH 0062/1733] [ja] Update docs/concepts/workloads/pods/pod-lifecycle.md to 1.19 --- .../concepts/workloads/pods/pod-lifecycle.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 8afc01295d..ea2f2116f0 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -8,7 +8,7 @@ weight: 30 このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 -Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。 +Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、回復させるためのアクションを決定します。 Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。 @@ -43,13 +43,13 @@ Podの各フェーズの値と意味は厳重に守られています。ここ これらが`phase`の取りうる値です。 -値 | 概要 -:-----|:----------- -`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。 -`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 -`Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。 -`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 -`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。 +値 | 概要 +:-----------|:----------- +`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。 +`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 +`Succeeded` | Pod内のすべてのコンテナが正常に終了し、再起動されません。 +`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 +`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。 Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。 @@ -69,7 +69,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME] ### `Running` {#container-state-running} -`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。 +`Running`状態はコンテナが問題なく実行されていることを示します。`postStart`フックが構成されていた場合、それはすでに実行されて終了しています。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。 ### `Terminated` {#container-state-terminated} @@ -81,7 +81,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME] Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。 -`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。 +`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。 ## PodのCondition {#pod-conditions} @@ -148,7 +148,7 @@ Podのコンテナは準備完了ですが、少なくとも1つのカスタム ## コンテナのProbe {#container-probes} -[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/reference/command-line-tools-reference/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 @@ -209,7 +209,7 @@ Podが削除されたときにリクエストを来ないようにするため ### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 @@ -220,7 +220,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。 -通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。 +通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。多くのコンテナランタイムは、コンテナイメージで定義されたSTOPSIGNAL値を尊重し、TERMの代わりにこれを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。 フローの例は下のようになります。 From f7e5f7cae04b704a1095264d7213ecab6cc85cf6 Mon Sep 17 00:00:00 2001 From: Jan Safranek Date: Wed, 10 Mar 2021 17:28:01 +0100 Subject: [PATCH 0063/1733] CSI migration of Cinder volume plugin is on by default Document that OpenStack Cinder CSI migration is enabled by default in Kubernetes 1.21 and that corresponding CSI driver must be installed. --- content/en/docs/concepts/storage/volumes.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 8d84a519c0..d56ac1f99c 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -208,14 +208,16 @@ spec: #### OpenStack CSI migration -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} -The `CSIMigration` feature for Cinder, when enabled, redirects all plugin operations -from the existing in-tree plugin to the `cinder.csi.openstack.org` Container -Storage Interface (CSI) Driver. In order to use this feature, the [OpenStack Cinder CSI -Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) -must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack` -beta features must be enabled. +The `CSIMigration` feature for Cinder is enabled by default in Kubernetes 1.21. +It redirects all plugin operations from the existing in-tree plugin to the +`cinder.csi.openstack.org` Container Storage Interface (CSI) Driver. +[OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) +must be installed on the cluster. +The feature can be disabled by un-setting `CSIMigrationOpenStack` beta feature +gate. When disabled, in-tree Cinder volume plugin will be responsible for +all storage related tasks, as it was in the previous Kubernetes releases. ### configMap From 91e45afd0d2b4cbacddb7ece605f2d60ba827004 Mon Sep 17 00:00:00 2001 From: KobayashiD27 Date: Thu, 11 Mar 2021 11:32:11 +0900 Subject: [PATCH 0064/1733] ja:Make ja/docs/concepts/architecture/nodes.md follow v1.19 of the original text --- content/ja/docs/concepts/architecture/nodes.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 9c47531a37..bf5fa1acb9 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -275,4 +275,3 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント * [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。 * アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。 * [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。 -* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。 From 1fbbac1888e165af51730f6179d49d5fd4e77005 Mon Sep 17 00:00:00 2001 From: KobayashiD27 Date: Thu, 11 Mar 2021 12:02:58 +0900 Subject: [PATCH 0065/1733] ja: Make docs/concepts/cluster-administration follow v1.19 of the original text --- .../cluster-administration/cluster-administration-overview.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 5d85797649..7d8cb8a8b3 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -29,8 +29,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る ## クラスターの管理 -* [クラスターの管理](/docs/tasks/administer-cluster/cluster-management/)では、クラスターのライフサイクルに関するいくつかのトピックを紹介しています。例えば、新規クラスターの作成、クラスターのマスターやワーカーノードのアップグレード、ノードのメンテナンスの実施(例: カーネルのアップグレード)、稼働中のクラスターのKubernetes APIバージョンのアップグレードについてです。 - * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。 * 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。 @@ -41,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る * [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。 -* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。 +* [Kubernetes APIへのアクセス制御](/docs/concepts/security/controlling-access)では、Kubernetesが自身のAPIに対するアクセスコントロールをどのように実装するかを説明します。 * [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。 From d65300986f6773d304f84943137f9b437c02058d Mon Sep 17 00:00:00 2001 From: CKchen0726 Date: Thu, 11 Mar 2021 11:11:39 +0800 Subject: [PATCH 0066/1733] fix spelling mistake in ./data/announcements/scheduled.yaml --- data/announcements/scheduled.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/data/announcements/scheduled.yaml b/data/announcements/scheduled.yaml index 1d5b330ac4..2eec2c1777 100644 --- a/data/announcements/scheduled.yaml +++ b/data/announcements/scheduled.yaml @@ -18,7 +18,7 @@ # title: "Sample 1 announcement" # # title is optional # message: | -# Message *one*. +# Message *one*. # [Hyperlink](https://en.wikipedia.org/wiki/Hyperlink). # # message is required. You can use Markdown. # - name: Sample 2 @@ -36,7 +36,7 @@ announcements: style: "background: #3d4cb7" title: | - KubeCon + CloudNativeCon NA 2020 virtual. + KubeCon + CloudNativeCon NA 2020 virtual. message: | 4 days of incredible opportunities to collaborate, learn, and share with the entire community!
November 17 – 20, 2020 @@ -47,7 +47,7 @@ announcements: style: "background: #3f0374" title: | - KubeCon + CloudNativeCon EU 2020 virtual. + KubeCon + CloudNativeCon EU 2020 virtual. message: | 4 days of incredible opportunities to collaborate, learn + share with the entire community!
August 17 – 20, 2020. From ae80ffb29f24eae2c0f7e1b63d44aa212e94ae8c Mon Sep 17 00:00:00 2001 From: Lapi Date: Thu, 11 Mar 2021 20:48:05 +0900 Subject: [PATCH 0067/1733] make docs/home/_index.md follow v1.19 of the original text --- content/ja/docs/home/_index.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index 7f8837ce60..3935a9b1ba 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -31,7 +31,7 @@ cards: button: "チュートリアルを見る" button_path: "/docs/tutorials" - name: setup - title: "クラスターを構築する" + title: "K8sクラスターを構築する" description: "リソースと要求に基づいて、Kubernetesを実行します。" button: "Kubernetesを構築する" button_path: "/docs/setup" @@ -55,9 +55,11 @@ cards: description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることができます。" button: "ドキュメントにコントリビュートする" button_path: /docs/contribute -- name: download - title: "Kubernetesをダウンロードする" +- name: release-notes + title: "K8sリリースノート" description: "もしKubernetesをインストールする、また最新バージョンにアップグレードする場合、最新のリリースノートを参照してください。" + button: "Kubernetesをダウンロードする" + button_path: "/docs/setup/release/notes" - name: about title: ドキュメントについて description: このWebサイトには、Kubernetesの最新バージョンと過去4世代のドキュメントが含まれています。 From e74dda647211815da633fa9000e35af49555f1da Mon Sep 17 00:00:00 2001 From: Yasuhisa Hayato Date: Sat, 13 Mar 2021 13:01:41 +0900 Subject: [PATCH 0068/1733] description of built-in node labels translate to Japanes Removed individual links and replaced them with reference links to pages --- .../concepts/scheduling-eviction/assign-pod-node.md | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 18b767cbb4..c1c0c95b6d 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -66,17 +66,7 @@ nodeSelectorを以下のように追加します: ## 補足: ビルトインNodeラベル {#built-in-node-labels} 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 -以下のようなラベルが該当します。 - -* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) -* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) -* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) -* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) -* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) -* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) -* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) -* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) -* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) +これらのラベルのリストは、[Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)を参照してください。 {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 From a34b9fc0153b85eaea9a962f90040392ce370fa0 Mon Sep 17 00:00:00 2001 From: Ryuichi KAWAMATA Date: Sat, 13 Mar 2021 16:53:28 +0900 Subject: [PATCH 0069/1733] Remove content/ja/docs/concepts/cluster-administration/cloud-providers.md (#26857) --- .../cluster-administration/cloud-providers.md | 327 ------------------ 1 file changed, 327 deletions(-) delete mode 100644 content/ja/docs/concepts/cluster-administration/cloud-providers.md diff --git a/content/ja/docs/concepts/cluster-administration/cloud-providers.md b/content/ja/docs/concepts/cluster-administration/cloud-providers.md deleted file mode 100644 index f5fc0fe845..0000000000 --- a/content/ja/docs/concepts/cluster-administration/cloud-providers.md +++ /dev/null @@ -1,327 +0,0 @@ ---- -title: クラウドプロバイダー -content_type: concept -weight: 30 ---- - - -このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。 - - -### kubeadm -[kubeadm](/ja/docs/reference/setup-tools/kubeadm/kubeadm/)は、Kubernetesクラスターを作成する選択肢として人気があります。 -kubeadmには、クラウドプロバイダーの設定情報を指定する設定オプションがあります。 -例えば、典型的なインツリークラウドプロバイダーは、以下のようにkubeadmを使用して設定することができます。 - -```yaml -apiVersion: kubeadm.k8s.io/v1beta2 -kind: InitConfiguration -nodeRegistration: - kubeletExtraArgs: - cloud-provider: "openstack" - cloud-config: "/etc/kubernetes/cloud.conf" ---- -apiVersion: kubeadm.k8s.io/v1beta2 -kind: ClusterConfiguration -kubernetesVersion: v1.13.0 -apiServer: - extraArgs: - cloud-provider: "openstack" - cloud-config: "/etc/kubernetes/cloud.conf" - extraVolumes: - - name: cloud - hostPath: "/etc/kubernetes/cloud.conf" - mountPath: "/etc/kubernetes/cloud.conf" -controllerManager: - extraArgs: - cloud-provider: "openstack" - cloud-config: "/etc/kubernetes/cloud.conf" - extraVolumes: - - name: cloud - hostPath: "/etc/kubernetes/cloud.conf" - mountPath: "/etc/kubernetes/cloud.conf" -``` - -典型的なインツリークラウドプロバイダーは、通常、[kube-apiserver](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)および[kube-controller-manager](ja//docs/reference/command-line-tools-reference/kube-controller-manager/)、[kubelet](/ja/docs/reference/command-line-tools-reference/kubelet/)のコマンドラインで指定される`--cloud-provider`と`--cloud-config`の両方が必要です。 -プロバイダーごとに`--cloud-config`で指定されるファイルの内容についても、以下に記載します。 - -すべての外部クラウドプロバイダーについては、以下の見出しに列挙されている個々のリポジトリーの案内に従ってください。または[すべてのリポジトリーのリスト](https://github.com/kubernetes?q=cloud-provider-&type=&language=)もご覧ください。 - -## AWS -ここでは、Amazon Web ServicesでKubernetesを実行する際に使用できるすべての設定について説明します。 - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)リポジトリーを参照してください。 - -### ノード名 - -AWSクラウドプロバイダーは、AWSインスタンスのプライベートDNS名をKubernetesのNodeオブジェクトの名前として使用します。 - -### ロードバランサー -以下のようにアノテーションを設定することで、[外部ロードバランサー](/ja/docs/tasks/access-application-cluster/create-external-load-balancer/)をAWS上で特定の機能を利用するように構成できます。 - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: example - namespace: kube-system - labels: - run: example - annotations: - service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value - service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http -spec: - type: LoadBalancer - ports: - - port: 443 - targetPort: 5556 - protocol: TCP - selector: - app: example -``` -AWSのロードバランサーサービスには、_アノテーション_ を使ってさまざまな設定を適用することができます。以下では、AWS ELBでサポートされているアノテーションについて説明します。 - -* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: アクセスログの送信間隔を指定するために使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: アクセスログを有効または無効にするためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: アクセスログ用のs3バケット名を指定するために使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: アクセスログ用のs3バケットのプレフィックスを指定するために使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: ELBに追加タグとして記録されるキーとバリューのペアのコンマ区切りリストとして指定するためにサービスで使用します。例えば、`"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`のように指定できます。 -* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: リスナーの背後にあるバックエンド(Pod)が使用するプロトコルを指定するためにサービスで使用します。`http`(デフォルト)または`https`を指定すると、接続を終端してヘッダーを解析するHTTPSリスナーが生成されます。`ssl`または`tcp`を指定すると、「生の」SSLリスナーが使われます。`http`を指定して`aws-load-balancer-ssl-cert`を使わない場合は、HTTPリスナーが使われます。 -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: セキュアなリスナーを要求するためにサービスで使用します。値は有効な証明書のARNです。詳細は、[ELBリスナーの設定](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)を参照してください。CertARNは、IAMまたはCM証明書のARNで、例えば`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`のようになります。 -* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 接続ドレインを有効または無効にするためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 接続ドレインのタイムアウトを指定するためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: アイドル接続タイムアウトを指定するためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: クロスゾーン負荷分散を有効または無効にするためにサービスで使用されます。 -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 作成されたELBに追加するセキュリティーグループを指定するために使用します。これは、以前にELBに割り当てられた他のすべてのセキュリティーグループを置き換えます。ここで定義されたセキュリティーグループは、サービス間で共有してはいけません。 -* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 作成されたELBに加える追加のセキュリティーグループを指定するためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-internal`: 内部ELBが必要であることを示すためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: ELB上でプロキシープロトコルを有効にするためにサービスで使用します。現在は、すべてのELBバックエンドでプロキシープロトコルを有効にすることを意味する`*`という値しか受け付けません。将来的には、特定のバックエンドでのみプロキシープロトコルを設定できるように調整できます。 -* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPSリスナーを使用するポートのコンマ区切りリストを指定するためにサービスで使用します。デフォルトは`*`(すべて)です。 - -AWSのアノテーションの情報は、[aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)のコメントから引用しています。 - -## Azure - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)リポジトリーを参照してください。 - -### ノード名 - -Azureクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名は、Azure VM名と一致しなければならないことに注意してください。 - -## CloudStack - -この外部クラウドプロバイダーを利用したい場合、[apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)リポジトリーを参照してください。 - -### ノード名 - -CloudStackクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。 - -## GCE - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)リポジトリーを参照してください。 - -### ノード名 - -GCEクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名の最初のセグメントは、GCEインスタンス名と一致しなければならないことに注意してください。例えば、`kubernetes-node-2.c.my-proj.internal`という名前のノードは、`kubernetes-node-2`という名前のインスタンスに対応していなければなりません。 - -## HUAWEI CLOUD - -この外部クラウドプロバイダーを利用したい場合、[kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)リポジトリーを参照してください。 - -### ノード名 - -HUAWEI CLOUDプロバイダーは、ノードのプライベートIPアドレスをKubernetesノード名として使用します。 -ノードでkubeletを開始するときは、必ず`--hostname-override=`を指定してください。 - -## OpenStack -ここでは、OpenStackでKubernetesを実行する際に使用できるすべての設定について説明します。 - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)リポジトリーを参照してください。 - -### ノード名 - -OpenStackクラウドプロバイダーは、インスタンス名(OpenStackのメタデータで決定されたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -インスタンス名は必ず、Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。 -kubeletがNodeオブジェクトを正常に登録できるように、インスタンス名は有効なKubernetesノード名である必要があります。 - -### サービス - -KubernetesのOpenStackクラウドプロバイダーの実装では、利用可能な場合、基盤となるクラウドからこれらのOpenStackのサービスの使用をサポートします。 - -| サービス名 | APIバージョン | 必須か | -|--------------------------|----------------|----------| -| Block Storage (Cinder) | V1†, V2, V3 | No | -| Compute (Nova) | V2 | No | -| Identity (Keystone) | V2‡, V3 | Yes | -| Load Balancing (Neutron) | V1§, V2 | No | -| Load Balancing (Octavia) | V2 | No | - -† Block Storage V1 APIのサポートは非推奨ですが、Kubernetes 1.9ではBlock Storage V3 APIのサポートが追加されました。 - -‡ Identity V2 APIのサポートは非推奨となり、将来のリリースでプロバイダーから削除される予定です。「Queens」のリリース時点で、OpenStackはIdentity V2 APIを公開しません。 - -§ Load Balancing V1 APIのサポートは、Kubernetes 1.9で削除されました。 - -サービスディスカバリーは、プロバイダー設定で提供される`auth-url`を使用して、OpenStack Identity(Keystone)が管理するサービスカタログを一覧表示することで実現されます。 -プロバイダーは、Keystone以外のOpenStackサービスが利用できなくなった場合には、機能を緩やかに低下させ、影響を受ける機能のサポートを放棄します。 -特定の機能は、基盤となるクラウドでNeutronが公開している拡張機能のリストに基づいて有効または無効にされます。 - -### cloud.conf -Kubernetesはcloud.confというファイルを介して、OpenStackとのやりとり方法を知っています。 -これは、KubernetesにOpenStack認証エンドポイントの認証情報と場所を提供するファイルです。 -ファイル内に以下の詳細を指定することで、cloud.confファイルを作成できます。 - -#### 典型的な設定 -以下の設定例は、最も頻繁に設定が必要な値に関するものです。 -プロバイダーをOpenStackクラウドのKeystoneエンドポイントに指定し、そのエンドポイントでの認証方法の詳細を提供し、さらにロードバランサーを設定します。 - -```yaml -[Global] -username=user -password=pass -auth-url=https:///identity/v3 -tenant-id=c869168a828847f39f7f06edd7305637 -domain-id=2a73b8f597c04551a0fdc8e95544be8a - -[LoadBalancer] -subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a -``` - -##### グローバル -これらのOpenStackプロバイダーの設定オプションは、グローバル設定に関連しており、`cloud.conf`ファイルの`[Global]`セクションに記述する必要があります。 - -* `auth-url`(必死): 認証に使用するKeystone APIのURLです。OpenStackのコントロールパネルでは、Access and Security > API Access > Credentialsで確認できます。 -* `username`(必須): Keystoneに設定されている有効なユーザーのユーザー名を参照します。 -* `password`(必須): Keystoneで設定された有効なユーザーのパスワードを参照します。 -* `tenant-id`(必須): リソースを作成するプロジェクトのIDを指定するために使用します。 -* `tenant-name`(任意): リソースを作成するプロジェクトの名前を指定します。 -* `trust-id`(任意): 認証に使用するtrustの識別子を指定するために使用します。trustは、ユーザー(委託者)が他のユーザー(受託者)に役割を委譲したり、受託者が委託者になりすますことを許可したりする権限を表します。利用可能なtrustは、Keystone APIの`/v3/OS-TRUST/trusts`エンドポイントの下にあります。 -* `domain-id`(任意): ユーザーが所属するドメインのIDを指定するために使用します。 -* `domain-name`(任意): ユーザーが所属するドメイン名を指定するために使用します。 -* `region`(任意): マルチリージョンのOpenStackクラウド上で実行する際に使うリージョンの識別子を指定するために使用します。リージョンはOpenStackデプロイメントの一般的な区分です。リージョンには厳密な地理的な意味合いはありませんが、デプロイメントでは`us-east`のような地理的な名前をリージョンの識別子に使うことができます。利用可能なリージョンはKeystone APIの`/v3/regions`エンドポイントの下にあります。 -* `ca-file`(任意): カスタムCAファイルのパスを指定するために使用します。 - - -テナントをプロジェクトに変更するKeystone V3を使用している場合、`tenant-id`の値は自動的にAPIのプロジェクト構造体にマッピングされます。 - -##### ロードバランサー -これらのOpenStackプロバイダーの設定オプションは、ロードバランサー設定に関連しており、`cloud.conf`ファイルの`[LoadBalancer]`セクションに記述する必要があります。 - -* `lb-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`または`v2`です。値が指定されていない場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。 -* `use-octavia`(任意): Octavia LBaaS V2サービスカタログエンドポイントを探して、利用するかどうかを決定するために使用します。有効な値は`true`または`false`です。`true`が指定され、Octaiva LBaaS V2エントリーが見つからなかった場合、プロバイダーはフォールバックして代わりにNeutron LBaaS V2エンドポイントを見つけようとします。デフォルト値は`false` です。 -* `subnet-id`(任意): ロードバランサーを作成したいサブネットのIDを指定します。Network > Networksにあります。サブネットを取得するには、それぞれのネットワークをクリックします。 -* `floating-network-id`(任意): 指定した場合、ロードバランサーのフローティングIPを作成します。 -* `lb-method`(任意): ロードバランサープールのメンバー間で負荷分散させるアルゴリズムを指定するために使用します。値には`ROUND_ROBIN`、`LEAST_CONNECTIONS`、`SOURCE_IP`を指定できます。何も指定しない場合のデフォルトの動作は`ROUND_ROBIN` です。 -* `lb-provider`(任意): ロードバランサーのプロバイダーを指定するために使用します。指定しない場合は、Neutronで設定されたデフォルトのプロバイダサービスが使用されます。 -* `create-monitor`(任意): Neutronロードバランサーのヘルスモニターを作成するかどうかを表します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`monitor-delay`、`monitor-timeout`、`monitor-max-retries`も設定しなければなりません。 -* `monitor-delay`(任意): ロードバランサーのメンバーにプローブを送信するまでの時間です。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。 -* `monitor-timeout`(任意): モニタリングがタイムアウトする前にpingの応答を待つための最大の時間です。この値はdelay値よりも小さくする必要があります。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。 -* `monitor-max-retries`(任意): ロードバランサーメンバーのステータスをINACTIVEに変更する前に許容されるpingの失敗の数です。1から10の間の数値でなければなりません。 -* `manage-security-groups`(任意): ロードバランサーがセキュリティーグループのルールを自動的に管理するかどうかを決定します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`node-security-group`も指定しなければなりません。 -* `node-security-group`(任意): 管理するセキュリティーグループのIDです。 - -##### ブロックストレージ -これらのOpenStackプロバイダーの設定オプションは、ブロックストレージ設定に関連しており、`cloud.conf`ファイルの`[BlockStorage]`セクションに記述する必要があります。 - -* `bs-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`、`v2`、`v3`、`auto`です。`auto`が指定された場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。何も指定しない場合のデフォルト値は`auto`です。 -* `trust-device-path`(任意): ほとんどのシナリオでは、Cinderが提供するブロックデバイス名(例: `/dev/vda`)は信頼できません。このブール値はこの動作をトグルします。`true`に設定すると、Cinderが提供するブロックデバイス名を信頼することになります。デフォルト値の`false`は、シリアル番号と`/dev/disk/by-id`のマッピングに基づいてデバイスのパスを検出します。 -* `ignore-volume-az`(任意): Cinderボリュームをアタッチする際のアベイラビリティーゾーンの使用に影響を与えます。NovaとCinderのアベイラビリティーゾーンが異なる場合は、`true`に設定する必要があります。これは、Novaのアベイラビリティーゾーンが多くあるにも関わらず、Cinderのアベイラビリティーゾーンが1つしかない場合によく見られます。デフォルト値は以前のリリースで使用されていた動作を維持するために`false`になっていますが、将来的には変更される可能性があります。 -* `node-volume-attach-limit`(任意): ノードにアタッチできるボリュームの最大数で、デフォルトはCinderの256です。 - -エンドポイントを区別するためにポートではなくパスを使用しているOpenStackデプロイメントにおいて、Kubernetesのバージョン1.8以下をデプロイする際、明示的に`bs-version`パラメーターの設定が必要な場合があります。パスベースのエンドポイントは`http://foo.bar/volume`の形式であり、ポートベースのエンドポイントは`http://foo.bar:xxx`の形式です。 - -パスベースのエンドポイントを使う環境で、Kubernetesが古い自動検出ロジックを使用している場合、ボリュームの切り離しを試みると`BS API version autodetection failed.`というエラーが返されます。この問題を回避するには、クラウドプロバイダー設定に以下のように追記することで、Cinder APIバージョン2を強制的に使用することができます。 - -```yaml -[BlockStorage] -bs-version=v2 -``` - -##### メタデータ -これらのOpenStackプロバイダーの設定オプションは、メタデータ設定に関連しており、`cloud.conf`ファイルの`[Metadata]`セクションに記述する必要があります。 - -* `search-order`(任意): この設定のキーは、プロバイダーが実行するインスタンスに関連するメタデータの取得方法に影響します。デフォルト値の`configDrive,metadataService`について、プロバイダーは、コンフィグドライブが利用可能な場合は最初にインスタンスに関連するメタデータをそこから取得し、次にメタデータサービスから取得します。代替値は以下の通りです。 - * `configDrive` - コンフィグドライブからのみ、インスタンスのメタデータを取得します。 - * `metadataService` - メタデータサービスからのみ、インスタンスのメタデータを取得します。 - * `metadataService,configDrive` - 最初にメタデータサービスからインスタンスのメタデータを取得し、次にコンフィグドライブから取得します。 - - コンフィグドライブ上のメタデータは時間の経過とともに陳腐化する可能性がありますが、メタデータサービスは常に最新の情報を提供するため、この動作を調整するのが望ましいです。しかし、すべてのOpenStackクラウドがコンフィグドライブとメタデータサービスの両方を提供しているわけではなく、どちらか一方しか利用できない場合もあるため、デフォルトでは両方をチェックするようになっています。 - -##### ルート -これらのOpenStackプロバイダーの設定オプションは、[kubenet](/ja/docs/concepts/cluster-administration/network-plugins/#kubenet)のKubernetesネットワークプラグインに関連しており、`cloud.conf`ファイルの`[Route]`セクションに記述する必要があります。 - - -* `router-id`(任意): 基盤となるクラウドのNeutronデプロイメントが`extraroutes`拡張機能をサポートしている場合は、`router-id`を使用してルートを追加するルーターを指定します。選択したルーターは、クラスターノードを含むプライベートネットワークにまたがっていなければなりません(通常、ノードネットワークは1つしかないので、この値はノードネットワークのデフォルトルーターになります)。この値は、OpenStackで[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)を使用するために必要です。 - -## OVirt - -### ノード名 - -OVirtクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名は、VMのFQDN(`...`の下でOVirtによって報告されたもの)と一致しなければならないことに注意してください。 - -## Photon - -### ノード名 - -Photonクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名はPhoton VM名と一致しなければならないことに注意してください(もしくは、`--cloud-config`で`overrideIP`がtrueに設定されている場合は、Kubernetesノード名はPhoton VMのIPアドレスと一致しなければなりません)。 - -## vSphere - -{{< tabs name="vSphere cloud provider" >}} -{{% tab name="vSphere 6.7U3以上" %}} -vSphere 6.7U3以上のすべてのvSphereデプロイメントでは、[external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere)と[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)の使用を推奨します。クイックスタートガイドについては、[Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)を参照してください。 -{{% /tab %}} -{{% tab name="vSphere 6.7U3未満" %}} -vSphere 6.7U3未満を実行している場合は、インツリーのvSphereクラウドプロバイダーを推奨します。クイックスタートガイドについては、[Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)を参照してください。 -{{% /tab %}} -{{< /tabs >}} - -vSphereクラウドプロバイダーの詳細なドキュメントについては、[vSphereクラウドプロバイダーのドキュメントサイト](https://cloud-provider-vsphere.sigs.k8s.io)を参照してください。 - -## IBM Cloud Kubernetes Service - -### コンピュートノード -IBM Cloud Kubernetes Serviceプロバイダーを使用することで、仮想ノードと物理ノード(ベアメタル)を混在させたクラスターを単一のゾーン、またはリージョン内の複数のゾーンにまたがって作成することができます。詳細については、[Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)を参照してください。 - -Kubernetes Nodeオブジェクトの名前は、IBM Cloud Kubernetes ServiceワーカーノードインスタンスのプライベートIPアドレスです。 - -### ネットワーク -IBM Cloud Kubernetes Serviceプロバイダーは、高品質なネットワークパフォーマンスとノードのネットワーク分離のためにVLANを提供します。カスタムファイアウォールやCalicoネットワークポリシーを設定して、クラスターにセキュリティーの追加レイヤーを加えたり、VPNを使用してクラスターをオンプレミスデータセンターに接続したりすることができます。詳細については、[Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)を参照してください。 - -アプリケーションをパブリックまたはクラスター内で公開するには、NodePort、LoadBalancer、Ingressサービスを利用できます。また、Ingressアプリケーションのロードバランサーをアノテーションでカスタマイズすることもできます。詳細については、[Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)を参照してください。 - -### ストレージ -IBM Cloud Kubernetes Serviceプロバイダーは、Kubernetesネイティブの永続ボリュームを活用して、ユーザーがファイル、ブロック、およびクラウドオブジェクトストレージをアプリケーションにマウントできるようにします。また、データの永続ストレージにDatabase as a Serviceやサードパーティーのアドオンを使用することもできます。詳しくは、[Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)を参照してください。 - -## Baidu Cloud Container Engine - -### ノード名 - -Baiduクラウドプロバイダーは、ノードのプライベートIPアドレス(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名はBaidu VMのプライベートIPと一致しなければならないことに注意してください。 - -## Tencent Kubernetes Engine - -この外部クラウドプロバイダーを利用したい場合、[TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)リポジトリーを参照してください。 - -### ノード名 - -Baiduクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名はTencent VMのプライベートIPと一致しなければならないことに注意してください。 - -## Alibaba Cloud Kubernetes - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)リポジトリーを参照してください。 - -### ノード名 - -Alibaba Cloudではノード名の書式は必要ありませんが、kubeletでは`--provider-id=${REGION_ID}.${INSTANCE_ID}`を追加する必要があります。パラメーター`${REGION_ID}`はKubernetesのリージョンのIDを、`${INSTANCE_ID}`はAlibaba ECS(Elastic Compute Service)のIDを表します。 - -### ロードバランサー - -[アノテーション](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)を設定することで、Alibaba Cloudの特定の機能を使用するように外部のロードバランサーを設定できます。 From fb402729919b66178722382231345127cfa9207f Mon Sep 17 00:00:00 2001 From: Ryuichi KAWAMATA Date: Sat, 13 Mar 2021 19:42:45 +0900 Subject: [PATCH 0070/1733] Update ja/docs/concepts/cluster-administration/networking.md --- .../cluster-administration/networking.md | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index b81c51f437..b94c9f6d15 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -39,7 +39,7 @@ Kubernetesは、ネットワークの実装に次の基本的な要件を課し このモデルは全体としてそれほど複雑ではないことに加え、KubernetesがVMからコンテナへのアプリへの移植を簡単にするという要望と基本的に互換性があります。ジョブがVMで実行されていた頃も、VMにはIPがあってプロジェクト内の他のVMと通信できました。これは同じ基本モデルです。 -KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。 +KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスとMACアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。 この実装方法は実際に使われているコンテナランタイムの詳細部分です。 @@ -51,6 +51,8 @@ KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内の この一覧はアルファベット順にソートされており、順序は優先ステータスを意味するものではありません。 +{{% thirdparty-content %}} + ### ACI [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. @@ -99,6 +101,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). +### Calico + +[Calico](https://docs.projectcalico.org/)は、コンテナ、仮想マシン、ホストベースのワークロードのためのオープンソースのネットワーク及びネットワークセキュリティのソリューションです。Calicoは、純粋なLinuxのeBPFデータプレーンや、Linuxの標準的なネットワークデータプレーン、WindowsのHNSデータプレーンを含む、複数のデータプレーンをサポートしています。Calicoは完全なネットワークスタックを提供していますが、[クラウドプロバイダーのCNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)と組み合わせてネットワークポリシーを提供することもできます。 + ### Cilium [Cilium](https://github.com/cilium/cilium) is open source software for @@ -129,6 +135,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100 entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the network complexity required to deploy Kubernetes at scale within AWS. +### Coil + +[Coil](https://github.com/cybozu-go/coil)は、容易に連携できるよう設計されていて、フレキシブルなEgressネットワークを提供することができるCNIプラグインです。 +Coilはベアメタルと比較して低いオーバーヘッドで操作することができ、また外部のネットワークへの任意のEgress NATゲートウェイを定義することができます。 + ### Contiv [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. @@ -266,14 +277,6 @@ stateful ACLs, load-balancers etc to build different virtual networking topologies. The project has a specific Kubernetes plugin and documentation at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). -### Project Calico - -[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine. - -Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall. - -Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking. - ### Romana [Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. @@ -287,9 +290,7 @@ or stand-alone. In either version, it doesn't require any configuration or extr to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes. - ## {{% heading "whatsnext" %}} ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 - From 45793339dd154a24ee599c59de082ed711877b77 Mon Sep 17 00:00:00 2001 From: RyuSA Date: Sat, 13 Mar 2021 22:58:11 +0900 Subject: [PATCH 0071/1733] bump docs up to v1.19 Update ja/docs/concepts/services-networking/service.md --- .../concepts/services-networking/service.md | 109 +++++++++++------- 1 file changed, 66 insertions(+), 43 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index d6894e959e..c93b0688e3 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -23,7 +23,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ ## Serviceを利用する動機 -{{< glossary_tooltip term_id="pod" text="Pod" >}}は停止が想定して設計されています。 Podが作成され、もしそれらが停止する時、Podは再作成されません。 +Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。 {{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。 各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。 @@ -35,7 +35,8 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ ## Serviceリソース {#service-resource} Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。 -ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。 +ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}}によって定義されます。 +その他の方法について知りたい場合は[セレクターなしのService](#services-without-selectors)を参照してください。 例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。— フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。 @@ -90,9 +91,9 @@ ServiceのデフォルトプロトコルはTCPです。また、他の[サポー Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化しますが、他の種類のバックエンドも抽象化できます。 例えば: - * プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合 - * Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合 - * ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合 +* プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合 +* Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合 +* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合 このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。 @@ -137,6 +138,7 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設 ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。 ### エンドポイントスライス + {{< feature-state for_k8s_version="v1.17" state="beta" >}} エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。 @@ -145,12 +147,10 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊 ### アプリケーションプロトコル -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} - -AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。 - -アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 +{{< feature-state for_k8s_version="v1.19" state="beta" >}} +`AppProtocol`フィールドによってServiceの各ポートに対して特定のアプリケーションプロトコルを指定することができます。 +この値は、対応するEndpointsオブジェクトとEndpointSliceオブジェクトに反映されます。 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies} Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。 @@ -162,9 +162,9 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。 Serviceにおいてプロキシーを使う理由はいくつかあります。 - * DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。 - * いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。 - * アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。 +* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。 +* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。 +* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。 ### user-spaceプロキシーモード {#proxy-mode-userspace} @@ -211,12 +211,12 @@ IPVSプロキシーモードはiptablesモードと同様に、netfilterのフ IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。 -- `rr`: ラウンドロビン -- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの) -- `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing) -- `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing) -- `sed`: 見込み遅延が最小なもの -- `nq`: キューなしスケジューリング +* `rr`: ラウンドロビン +* `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの) +* `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing) +* `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing) +* `sed`: 見込み遅延が最小なもの +* `nq`: キューなしスケジューリング {{< note >}} IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。 @@ -282,7 +282,7 @@ PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数( [makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 -例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。 +例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。 ```shell REDIS_MASTER_SERVICE_HOST=10.0.0.11 @@ -308,12 +308,12 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。 もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。 -例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。 -`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。 +例えば、Kubernetesの`my-ns`というNamespace内で`my-service`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`my-service.my-ns`というDNSレコードを作成します。 +`my-ns`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`my-service.my-ns`でも動作します)。 他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。 -Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。 +Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`my-service.my-ns`というServiceが`http`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`http`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。 KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。 [DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。 @@ -337,8 +337,8 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一 ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。 しかしDNSのシステムは下記の2つ両方を探索し、設定します。 - * [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード - * 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード +* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード +* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード ## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types} @@ -349,16 +349,15 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類 `Type`項目の値と、そのふるまいは以下のようになります。 - * `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。 - * [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`:`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。 - * [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。 - * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。 +* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。 +* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`:`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。 +* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。 +* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。 + {{< note >}} + `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。 + {{< /note >}} - {{< note >}} - `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。 - {{< /note >}} - -また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。 +また、Serviceを公開するために[Ingress](/ja/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。 Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。 ### NodePort タイプ {#nodeport} @@ -461,6 +460,7 @@ Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部 タブを選択してください。 {{% /tab %}} {{% tab name="GCP" %}} + ```yaml [...] metadata: @@ -469,8 +469,10 @@ metadata: cloud.google.com/load-balancer-type: "Internal" [...] ``` + {{% /tab %}} {{% tab name="AWS" %}} + ```yaml [...] metadata: @@ -479,8 +481,10 @@ metadata: service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 [...] ``` + {{% /tab %}} {{% tab name="Azure" %}} + ```yaml [...] metadata: @@ -489,8 +493,10 @@ metadata: service.beta.kubernetes.io/azure-load-balancer-internal: "true" [...] ``` + {{% /tab %}} {{% tab name="IBM Cloud" %}} + ```yaml [...] metadata: @@ -502,6 +508,7 @@ metadata: {{% /tab %}} {{% tab name="OpenStack" %}} + ```yaml [...] metadata: @@ -510,8 +517,10 @@ metadata: service.beta.kubernetes.io/openstack-internal-load-balancer: "true" [...] ``` + {{% /tab %}} {{% tab name="Baidu Cloud" %}} + ```yaml [...] metadata: @@ -520,8 +529,10 @@ metadata: service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" [...] ``` + {{% /tab %}} {{% tab name="Tencent Cloud" %}} + ```yaml [...] metadata: @@ -529,6 +540,7 @@ metadata: service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx [...] ``` + {{% /tab %}} {{< /tabs >}} @@ -675,8 +687,16 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく # この値はservice.beta.kubernetes.io/aws-load-balancer-healthcheck-intervalの値以下である必要があります。 # デフォルトでは5 この値は2から60の間で設定可能 + service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" + # ELBが作成される際に追加されるセキュリティグループのリスト + # service.beta.kubernetes.io/aws-load-balancer-extra-security-groupsアノテーションと異なり + # 元々ELBに付与されていたセキュリティグループを置き換えることになります。 + service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" # ELBに追加される予定のセキュリティーグループのリスト + + service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" + # ロードバランサーがターゲットノードを指定する際に利用するキーバリューのペアのコンマ区切りリストです。 ``` #### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support} @@ -738,8 +758,9 @@ spec: annotations: # 指定したノードでロードバランサーをバインドします service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2) + # 既存のロードバランサーのID - service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx + service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません service.kubernetes.io/service.extensiveParameters: "" @@ -750,11 +771,14 @@ spec: # ロードバランサーのタイプを指定します # 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer) service.kubernetes.io/loadbalance-type: xxxxx + # パブリックネットワーク帯域幅の課金方法を指定します # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth) service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx + # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。 service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10" + # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します # そうでない場合、すべてのノードが登録されます service.kubernetes.io/local-svc-only-bind-node-with-pod: true @@ -777,6 +801,7 @@ spec: type: ExternalName externalName: my.database.example.com ``` + {{< note >}} ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。 IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。 @@ -914,12 +939,12 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。 {{< note >}} -ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。 +ユーザーはまた、HTTP/HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。 {{< /note >}} ### PROXY プロトコル -もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。 +もしクラウドプロバイダーがサポートしている場合、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。 ロードバランサーは、最初の一連のオクテットを送信します。 下記のような例となります。 @@ -927,15 +952,16 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで ``` PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n ``` + クライアントからのデータのあとに追加されます。 ### SCTP -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、EndpointSlice、NetworkPolicyとPodの定義において`protocol`フィールドの値でSCTPをサポートしています。ベータ版の機能のため、この機能はデフォルトで有効になっています。SCTPをクラスターレベルで無効にするには、クラスター管理者はAPI Serverにおいて`SCTPSupport` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を`--feature-gates=SCTPSupport=false,…`と設定して無効にする必要があります。 -そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 +そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、EndpointSlice、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 #### 警告 {#caveat-sctp-overview} @@ -967,11 +993,8 @@ SCTPはWindowsベースのNodeではサポートされていません。 kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。 {{< /warning >}} - - ## {{% heading "whatsnext" %}} - * [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。 * [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 From 745b68888d2906b6810bd4ff2eb8721239611015 Mon Sep 17 00:00:00 2001 From: RyuSA Date: Sat, 13 Mar 2021 23:02:03 +0900 Subject: [PATCH 0072/1733] Update some links from en-page to ja-page --- content/ja/docs/concepts/services-networking/service.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index c93b0688e3..d104f3e992 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -143,7 +143,7 @@ ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊 エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。 -エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。 +エンドポイントスライスは、[エンドポイントスライスのドキュメント](/ja/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。 ### アプリケーションプロトコル @@ -995,6 +995,6 @@ kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理 ## {{% heading "whatsnext" %}} -* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。 -* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 -* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 +* [Connecting Applications with Services](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。 +* [Ingress](/ja/docs/concepts/services-networking/ingress/)を参照してください。 +* [EndpointSlices](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。 From 2ce5be43779ffb360ebc1ec4532c0287ee5f9ee1 Mon Sep 17 00:00:00 2001 From: Genki Ogasawara Date: Sun, 14 Mar 2021 10:25:37 +0900 Subject: [PATCH 0073/1733] modify: content/ja/docs/concepts/workloads/controllers/replicaset.md --- content/ja/docs/concepts/workloads/controllers/replicaset.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index 9f8ccfc377..d2dcaf232d 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -197,7 +197,7 @@ ReplicaSetオブジェクトの名前は、有効な ### Pod テンプレート -`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 +`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/docs/concepts/workloads/pods/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。 テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。 @@ -300,7 +300,7 @@ ReplicaSetは、Node上のいくつかのエージェント(例えば、Kubelet ### Job -PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用してください。 +PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/workloads/controllers/job/)を使用してください。 ### DaemonSet From 045265b044a6171cef39fef1a872e24126b64c2d Mon Sep 17 00:00:00 2001 From: Genki Ogasawara Date: Sun, 14 Mar 2021 10:32:03 +0900 Subject: [PATCH 0074/1733] modify: content/ja/docs/concepts/workloads/controllers/replicaset.md --- content/ja/docs/concepts/workloads/controllers/replicaset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index d2dcaf232d..f2317706cf 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -197,7 +197,7 @@ ReplicaSetオブジェクトの名前は、有効な ### Pod テンプレート -`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/docs/concepts/workloads/pods/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 +`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。 テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。 From b9c6c57377c37301625b39892622205cdb0bb4eb Mon Sep 17 00:00:00 2001 From: RyuSA Date: Sun, 14 Mar 2021 12:43:06 +0900 Subject: [PATCH 0075/1733] Update content/ja/docs/concepts/services-networking/service.md Pods to Pod --- content/ja/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index d104f3e992..1b878eeda0 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -23,7 +23,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ ## Serviceを利用する動機 -Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。 +Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。 {{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。 各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。 From 12bc83471fbd51178ed54eff124d57c90b64720e Mon Sep 17 00:00:00 2001 From: JIIOryo Date: Sun, 14 Mar 2021 20:46:21 +0900 Subject: [PATCH 0076/1733] Update: ja/docs/concepts/workloads/controllers/deployment.md --- .../ja/docs/concepts/workloads/controllers/deployment.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index e2d720323d..de2388ebee 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -95,7 +95,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください コマンドの実行結果は以下のとおりです。 ```shell Waiting for rollout to finish: 2 out of 3 new replicas have been updated... - deployment.apps/nginx-deployment successfully rolled out + deployment "nginx-deployment" successfully rolled out ``` 4. 数秒後、再度`kubectl get deployments`を実行してください。 @@ -194,7 +194,7 @@ Deploymentを更新するには以下のステップに従ってください。 ``` もしくは ``` - deployment.apps/nginx-deployment successfully rolled out + deployment "nginx-deployment" successfully rolled out ``` 更新されたDeploymentのさらなる情報を取得するには、以下を確認してください。 @@ -788,7 +788,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment 実行結果は以下のとおりです。 ``` Waiting for rollout to finish: 2 of 3 updated replicas are available... -deployment.apps/nginx-deployment successfully rolled out +deployment "nginx-deployment" successfully rolled out ``` そして`kubectl rollout`の終了ステータスが0となります（成功です）: ```shell From 11b5df1932cc83e418342f2fb79d0fe5e6a0e0e7 Mon Sep 17 00:00:00 2001 From: JIIOryo Date: Sun, 14 Mar 2021 21:27:15 +0900 Subject: [PATCH 0077/1733] Update: ja/docs/concepts/workloads/pods/init-containers.md --- content/ja/docs/concepts/workloads/pods/init-containers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 5e7baf0665..4cf7d75fae 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -20,7 +20,7 @@ Initコンテナは下記の項目をのぞいて、通常のコンテナと全 * Initコンテナは常に完了するまで稼働します。 * 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。 -もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`がNeverの場合、再起動されません。 +もしあるPodの単一のInitコンテナが失敗した場合、Kubeletは成功するまで何度もそのInitコンテナを再起動します。しかし、もしそのPodの`restartPolicy`がNeverで、そのPodの起動時にInitコンテナが失敗した場合、KubernetesはそのPod全体を失敗として扱います。 PodにInitコンテナを指定するためには、Podの仕様にそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトの配列として指定してください。 Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。 From 57ade89fb0b842488b8a8bd2ce6ce434b76f9c74 Mon Sep 17 00:00:00 2001 From: katsuhisa91 <91katsuhisa@gmail.com> Date: Sun, 14 Mar 2021 23:50:24 +0900 Subject: [PATCH 0078/1733] [ja] Update docs/concepts/workloads/controllers/daemonset.md to follow v1.19 of the original text --- content/ja/docs/concepts/workloads/controllers/daemonset.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 363a549997..7d2d55febb 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -70,8 +70,6 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。 -また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。 - ### 選択したNode上でPodを稼働させる もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node From 2b18c86f244edb577fcc78d003ae3174dd4d9ac9 Mon Sep 17 00:00:00 2001 From: Yecheng Fu Date: Thu, 25 Feb 2021 16:23:47 +0800 Subject: [PATCH 0079/1733] add VolumeCapacityPriority feature gate Co-authored-by: Wei Huang --- .../command-line-tools-reference/feature-gates.md | 3 +++ content/en/docs/reference/scheduling/config.md | 7 ++++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 51c13f528f..8c606d001d 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -346,6 +346,7 @@ different Kubernetes components. | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | | `TokenRequestProjection` | `true` | Beta | 1.12 | 1.19 | | `TokenRequestProjection` | `true` | GA | 1.20 | - | +| `VolumeCapacityPriority` | `false` | Alpha | 1.21 | | | `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 | | `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | 1.19 | | `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - | @@ -777,6 +778,8 @@ Each feature gate is designed for enabling/disabling a specific feature: - `TopologyManager`: Enable a mechanism to coordinate fine-grained hardware resource assignments for different components in Kubernetes. See [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/). +- 'VolumeCapacityPriority`: Enable support for prioritizing nodes in different + topologies based on available PV capacity. - `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource. - `VolumeScheduling`: Enable volume topology aware scheduling and make the PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also diff --git a/content/en/docs/reference/scheduling/config.md b/content/en/docs/reference/scheduling/config.md index 7754d7cb7d..d963d56c92 100644 --- a/content/en/docs/reference/scheduling/config.md +++ b/content/en/docs/reference/scheduling/config.md @@ -145,7 +145,12 @@ extension points: Extension points: `Score`. - `VolumeBinding`: Checks if the node has or if it can bind the requested {{< glossary_tooltip text="volumes" term_id="volume" >}}. - Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`. + Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`. + {{< note >}} + `Score` extension point is enabled when `VolumeCapacityPriority` feature is + enabled. It prioritizes the smallest PVs that can fit the requested volume + size. + {{< /note >}} - `VolumeRestrictions`: Checks that volumes mounted in the node satisfy restrictions that are specific to the volume provider. Extension points: `Filter`. From 004df073c410dd4151752305362cce48c2aeae80 Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 15 Mar 2021 00:29:41 +0200 Subject: [PATCH 0080/1733] [vi] update invalid web page link for api group --- .../vi/docs/reference/glossary/api-group.md | 4 +- .../vi/docs/reference/kubectl/cheatsheet.md | 760 +++++++++--------- 2 files changed, 382 insertions(+), 382 deletions(-) diff --git a/content/vi/docs/reference/glossary/api-group.md b/content/vi/docs/reference/glossary/api-group.md index ce2cfd4532..66c215e0a6 100644 --- a/content/vi/docs/reference/glossary/api-group.md +++ b/content/vi/docs/reference/glossary/api-group.md @@ -2,7 +2,7 @@ title: API Group id: api-group date: 2019-12-16 -full_link: /docs/concepts/overview/kubernetes-api/#api-groups +full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning short_description: > Một tập những đường dẫn tương đối đến Kubernetes API. @@ -18,4 +18,4 @@ Một tập những đường dẫn tương đối đến Kubernetes API. Bạn có thể cho phép hay vô hiệu từng API group bằng cách thay đổi cấu hình trên API server của mình. Đồng thời bạn cũng có thể vô hiệu hay kích hoạt các đường dẫn cho những tài nguyên cụ thể. API group đơn giản hóa việc mở rộng Kubernetes API. Nó được chỉ định dưới dạng REST và trong trường `apiVersion` của một đối tượng đã được chuyển hóa. -- Đọc thêm về [API Group](/docs/concepts/overview/kubernetes-api/#api-groups). \ No newline at end of file +- Đọc thêm về [API Group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning). \ No newline at end of file diff --git a/content/vi/docs/reference/kubectl/cheatsheet.md b/content/vi/docs/reference/kubectl/cheatsheet.md index 38e51750e6..079b36a42b 100644 --- a/content/vi/docs/reference/kubectl/cheatsheet.md +++ b/content/vi/docs/reference/kubectl/cheatsheet.md @@ -1,381 +1,381 @@ ---- -title: kubectl Cheat Sheet -reviewers: -- ngtuna -content_type: concept -card: - name: reference - weight: 30 ---- - - - -Xem thêm: [Kubectl Overview](/docs/reference/kubectl/overview/) và [JsonPath Guide](/docs/reference/kubectl/jsonpath). - -Trang này là trang tổng quan của lệnh `kubectl`. - - - - - -# kubectl - Cheat Sheet - -## Kubectl Autocomplete - -### BASH - -```bash -source <(kubectl completion bash) # thiết lập autocomplete trong bash vào shell hiện tại, gói bash-completion nên được cài đặt trước tiên -echo "source <(kubectl completion bash)" >> ~/.bashrc # thêm vĩnh viễn autocomplete vào trong bash shell -``` - -Bạn có thể dùng một alias cho `kubectl` cũng hoạt động với completion: - -```bash -alias k=kubectl -complete -F __start_kubectl k -``` - -### ZSH - -```bash -source <(kubectl completion zsh) # thiết lập autocomplete trong zsh vào shell hiện tại -echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # thêm vĩnh viễn autocomplete vào trong zsh shell -``` - -## Ngữ cảnh và cấu hình kubectl - -Thiết lập cụm Kubernetes nào mà `kubectl` sẽ giao tiếp với và sửa đổi thông tin cấu hình. -Xem tài liệu [Xác thực giữa các cụm với kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) -để biết thông tin chi tiết của tệp cấu hình. - -```bash -kubectl config view # Hiển thị các thiết lập kubeconfig đã được merged - -# sử dụng nhiều tệp kubeconfig cùng một lúc và xem cấu hình hợp nhất -KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 - -kubectl config view - -# lấy mật khẩu cho người dùng e2e -kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' - -kubectl config view -o jsonpath='{.users[].name}' # hiển thị người dùng đầu tiên -kubectl config view -o jsonpath='{.users[*].name}' # lấy danh sách người dùng -kubectl config get-contexts # hiển thị danh sách các ngữ cảnh -kubectl config current-context # hiển thị ngữ cảnh hiện tại -kubectl config use-context my-cluster-name # thiết lập ngữ cảnh mặc định cho my-cluster-name - -# thêm một cụm mới vào kubeconf hỗ trợ xác thực cơ bản -kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword - -# lưu vĩnh viễn namespace cho tất cả các lệnh kubectl tiếp theo trong ngữ cảnh đó -kubectl config set-context --current --namespace=ggckad-s2 - -# thiết lập ngữ cảnh sử dụng tên người dùng và namespace cụ thể -kubectl config set-context gce --user=cluster-admin --namespace=foo \ - && kubectl config use-context gce - -kubectl config unset users.foo # xóa người dùng foo -``` - -## Apply -`apply` quản lý các ứng dụng thông qua các tệp định nghĩa tài nguyên Kubernetes. Nó tạo và cập nhật các tài nguyên trong một cụm thông qua việc chạy `kubectl apply`. Đây là cách được đề xuất để quản lý các ứng dụng Kubernetes trong thực tế. Xem thêm [Kubectl Book](https://kubectl.docs.kubernetes.io). - -## Tạo một đối tượng - -Kubernetes manifests có thể được định nghĩa trong tệp json hoặc yaml. Phần mở rộng `.yaml`, -`.yml`, và `.json` có thể được dùng. - -```bash -kubectl apply -f ./my-manifest.yaml # tạo tài nguyên -kubectl apply -f ./my1.yaml -f ./my2.yaml # tạo từ nhiều tệp -kubectl apply -f ./dir # tạo tài nguyên từ tất cả các tệp manifest trong thư mục dir -kubectl apply -f https://git.io/vPieo # tạo tài nguyên từ url -kubectl create deployment nginx --image=nginx # tạo một deployment nginx -kubectl explain pods,svc # lấy thông tin pod và service manifest - -# Tạo nhiều đối tượng YAML từ stdin -cat < pod.yaml - -kubectl attach my-pod -i # Đính kèm với container đang chạy -kubectl port-forward my-pod 5000:6000 # Lắng nghe trên cổng 5000 của máy local và chuyển tiếp sang cổng 6000 trên pod my-pod -kubectl exec my-pod -- ls / # Chạy lệnh trong một pod (trường hợp 1 container) -kubectl exec my-pod -c my-container -- ls / # Chạy lệnh trong pod (trường hợp nhiều container) -kubectl top pod POD_NAME --containers # Hiển thị số liệu của pod và container chạy trong nó -``` - -## Tương tác với các nodes và cụm - -```bash -kubectl cordon my-node # Đánh dấu my-node là không thể lập lịch -kubectl drain my-node # Gỡ my-node ra khỏi cụm để chuẩn bị cho việc bảo trì -kubectl uncordon my-node # Đánh dấu my-node có thể lập lịch trở lại -kubectl top node my-node # Hiển thị số liệu của node -kubectl cluster-info # Hiển thị địa chỉ master và các services -kubectl cluster-info dump # Kết xuất trạng thái hiện tại của cụm ra ngoài stdout -kubectl cluster-info dump --output-directory=/path/to/cluster-state # Kết xuất trạng thái hiện tại của cụm vào /path/to/cluster-state - -kubectl taint nodes foo dedicated=special-user:NoSchedule -``` - -### Các loại tài nguyên - -Liệt kê tất cả các loại tài nguyên được hỗ trợ cùng với tên viết tắt của chúng, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), cho dù chúng là [namespaced](/docs/concepts/overview/working-with-objects/namespaces), và [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): - -```bash -kubectl api-resources -``` - -Các hoạt động khác để khám phá các tài nguyên API: - -```bash -kubectl api-resources --namespaced=true # Tất cả các tài nguyên được đặt tên -kubectl api-resources --namespaced=false # Tất cả các tài nguyên không được đặt tên -kubectl api-resources -o name # Tất cả các tài nguyên với đầu ra đơn giản (chỉ gồm tên tài nguyên) -kubectl api-resources -o wide # Tất cả các tài nguyên với đầu ra mở rộng -kubectl api-resources --verbs=list,get # Tất cả các tài nguyên hỗ trợ yêu cầu "list" và "get" -kubectl api-resources --api-group=extensions # Tất cả tài nguyên trong nhóm API "tiện ích mở rộng" -``` - -### Định dạng đầu ra - -Để xuất thông tin chi tiết ra cửa sổ terminal của bạn theo một định dạng cụ thể, bạn có thể thêm các cờ `-o` hoặc `--output` vào lệnh `kubectl` được hỗ trợ. - -Định dạng đầu ra | Mô tả ---------------| ----------- -`-o=custom-columns=` | In một bảng bằng danh sách, các cột tùy chỉnh được phân tách bằng dấu phẩy -`-o=custom-columns-file=` | In một bảng bằng cách sử dụng mẫu cột tùy chỉnh trong tệp `` -`-o=json` | Xuất ra một đối tượng API theo định dạng JSON -`-o=jsonpath=
--enable-admission-plugins stringSlice
admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The `DynamicKubeletConfig` feature gate must be enabled to pass this flag; this gate currently defaults to `true` because the feature is beta.
--enable-cadvisor-json-endpoints     Default: `false`
Enable cAdvisor json `/spec` and `/stats/*` endpoints. This flag has no effect on the /stats/summary endpoint. (DEPRECATED: will be removed in a future version)
--enable-controller-attach-detach     Default: `true`
--enable-cadvisor-json-endpoints     Default: `false`
- -启用 cAdvisor JSON 数据的 /spec 和 /stats/* 端点。 -已弃用：未来版本将会移除此标志。 -
--enable-controller-attach-detach     默认值：true