kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.25

pull/36053/head
carolina valencia 2022-08-18 15:58:41 -03:00
parent dacf474354 7c89f5675a
commit 6810fa976d
322 changed files with 10781 additions and 7186 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.gitignore vendored
View File

@ -27,14 +27,14 @@ kubernetes.github.io.iml
nohup.out
# Hugo output
public/
resources/
/public/
/resources/
.hugo_build.lock
# Netlify Functions build output
package-lock.json
functions/
node_modules/
/functions/
/node_modules/
# Generated files when building with make container-build
.config/

3
OWNERS
View File

@ -7,12 +7,13 @@ approvers:
- sig-docs-en-owners # Defined in OWNERS_ALIASES
emeritus_approvers:
# - celestehorgan, commented out to disable PR assignments
# - chenopis, commented out to disable PR assignments
# - irvifa, commented out to disable PR assignments
# - jaredbhatti, commented out to disable PR assignments
# - kbarnard10, commented out to disable PR assignments
# - steveperry-53, commented out to disable PR assignments
- stewart-yu
- stewart-yu
# - zacharysarah, commented out to disable PR assignments
labels:

9
OWNERS_ALIASES
View File

@ -20,7 +20,6 @@ aliases:
sig-docs-en-owners: # Admins for English content
- annajung
- bradtopol
- celestehorgan
- divya-mohan0209
- jimangel
- jlbutler
@ -33,10 +32,8 @@ aliases:
- savitharaghunathan
- sftim
- tengqm
- zacharysarah
sig-docs-en-reviews: # PR reviews for English content
- bradtopol
- celestehorgan
- daminisatya
- divya-mohan0209
- jimangel
@ -48,7 +45,6 @@ aliases:
- sftim
- shannonxtreme
- tengqm
- zacharysarah
sig-docs-es-owners: # Admins for Spanish content
- raelga
- electrocucaracha
@ -86,11 +82,10 @@ aliases:
sig-docs-hi-owners: # Admins for Hindi content
- anubha-v-ardhan
- divya-mohan0209
- mittalyashu
sig-docs-hi-reviews: # PR reviews for Hindi content
- anubha-v-ardhan
- divya-mohan0209
- mittalyashu
- Garima-Negi
- verma-kunal
sig-docs-id-owners: # Admins for Indonesian content
- ariscahyadi
@ -130,12 +125,14 @@ aliases:
- nasa9084
# oke-py
- ptux
- t-inu
sig-docs-ko-owners: # Admins for Korean content
- ClaudiaJKang
- gochist
- ianychoi
- jihoon-seo
- seokho-son
- yoonian
- ysyukr
sig-docs-ko-reviews: # PR reviews for Korean content
- ClaudiaJKang

2
config.toml
View File

@ -15,7 +15,7 @@ disableKinds = ["taxonomy", "taxonomyTerm"]
ignoreFiles = [ "(?:^|/)OWNERS$", "README[-]+[a-z]*\\.md", "^node_modules$", "content/en/docs/doc-contributor-tools" ]
timeout = 3000
timeout = "180s"
# Highlighting config.
pygmentsCodeFences = true

4
content/de/docs/concepts/_index.md
View File

@ -20,14 +20,14 @@ welche Anwendungen oder anderen Workloads Sie ausführen möchten, welche Contai
Sobald Sie den gewünschten Status eingestellt haben, wird das *Kubernetes Control Plane* dafür sorgen, dass der aktuelle Status des Clusters mit dem gewünschten Status übereinstimmt. Zu diesem Zweck führt Kubernetes verschiedene Aufgaben automatisch aus, z. B. das Starten oder Neustarten von Containern, Skalieren der Anzahl der Repliken einer bestimmten Anwendung und vieles mehr. Das Kubernetes Control Plane besteht aus einer Reihe von Prozessen, die in Ihrem Cluster ausgeführt werden:
* Der **Kubernetes Master** bestehet aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind:[kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
* Der **Kubernetes Master** besteht aus drei Prozessen, die auf einem einzelnen Node in Ihrem Cluster ausgeführt werden, der als Master-Node bezeichnet wird. Diese Prozesse sind: [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) und [kube-scheduler](/docs/admin/kube-scheduler/).
* Jeder einzelne Node in Ihrem Cluster, welcher nicht der Master ist, führt zwei Prozesse aus:
* **[kubelet](/docs/admin/kubelet/)**, das mit dem Kubernetes Master kommuniziert.
* **[kube-proxy](/docs/admin/kube-proxy/)**, ein Netzwerk-Proxy, der die Netzwerkdienste von Kubernetes auf jedem Node darstellt.
## Kubernetes Objects
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt; Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
Kubernetes enthält eine Reihe von Abstraktionen, die den Status Ihres Systems darstellen: im Container eingesetzte Anwendungen und Workloads, die zugehörigen Netzwerk- und Festplattenressourcen sowie weitere Informationen zu den Aufgaben Ihres Clusters. Diese Abstraktionen werden durch Objekte in der Kubernetes-API dargestellt. Lesen Sie [Kubernetes Objects Überblick](/docs/concepts/abstractions/overview/) für weitere Details.
Die Basisobjekte von Kubernetes umfassen:

6
content/de/docs/concepts/containers/images.md
View File

@ -5,7 +5,7 @@ weight: 10
---
<!-- overview -->
Sie erstellen ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann.
Sie erstellen Ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann.
Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags.
@ -75,7 +75,7 @@ Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden:
- Alle Pods können jedes gecachte Image auf einem Node nutzen
- Setzt root - Zugriff auf allen Nodes zum Einrichten voraus
- Spezifizieren eines ImagePullSecrets auf einem Pod
- Nur Pods, die eigene Secret tragen, haben Zugriff auf eine private Registry
- Nur Pods, die eigene Secrets tragen, haben Zugriff auf eine private Registry
Jede Option wird im Folgenden im Detail beschrieben
@ -246,7 +246,7 @@ Falls jedoch die `imagePullPolicy` Eigenschaft der Containers auf `IfNotPresent`
Wenn Sie sich auf im Voraus heruntergeladene Images als Ersatz für eine Registry - Authentifizierung verlassen möchten, müssen sie sicherstellen, dass alle Knoten die gleichen, im Voraus heruntergeladenen Images aufweisen.
Diese Medthode kann dazu genutzt werden, bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
Diese Methode kann dazu genutzt werden, bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen.
Alle Pods haben Leserechte auf alle im Voraus geladenen Images.

32
content/de/docs/concepts/workloads/pods/_index.md
View File

@ -130,13 +130,13 @@ enthaltenen Container bereit:
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
Einweg-Einheiten konzipiert sind. Wenn ein Pod erstellt wird (entweder direkt
von Ihnen oder indirekt von einem
{{<glossary_tooltip text="Controller" term_id="controller">}}), wird die
Ausführung auf einem {{<glossary_tooltip term_id="node">}} 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.
mangelnder Ressourcen *evakuiert* wird oder der Node ausfällt.
{{< note >}}
Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten
@ -163,20 +163,20 @@ verwalten:
* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}
* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}
### Pod Vorlagen
### Pod-Vorlagen
Controller für
{{<glossary_tooltip text="Workload" term_id="workload">}}-Ressourcen
erstellen Pods von einer _Pod Vorlage_ und verwalten diese Pods für dich.
erstellen Pods von einer _Pod-Vorlage_ und verwalten diese Pods für dich.
Pod Vorlagen 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 Pod Vorlage innerhalb
des Workload-Objektes, um Pods zu erzeugen. Die Pod Vorlage ist Teil des
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.
@ -191,29 +191,29 @@ metadata:
name: hello
spec:
template:
# Dies is the Pod Vorlage
# Dies is the Pod-Vorlage
spec:
containers:
- name: hello
image: busybox
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
# Die Pod Vorlage endet hier
# Die Pod-Vorlage endet hier
```
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
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 Pod Vorlage
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 Pod Vorlage. Wenn du mehr über StatefulSet erfahren möchtest,
Ä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.
@ -221,7 +221,7 @@ im Tutorial StatefulSet Basics.
Auf Nodes beobachtet oder verwaltet das
{{< glossary_tooltip term_id="kubelet" text="Kubelet" >}}
nicht direkt die Details zu Pod Vorlagen 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.
@ -229,7 +229,7 @@ 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 Pod Vorlage 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 dich nicht daran, Pods direkt zu verwalten. Es ist möglich,
@ -366,4 +366,4 @@ kannst du Artikel zu früheren Technologien lesen, unter anderem:
* [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/).
* [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/).

27
content/en/blog/_posts/2022-08-04-kubernetes-1.24-deprecations-and-removals.md → content/en/blog/_posts/2022-08-04-kubernetes-1.25-deprecations-and-removals.md
View File

@ -19,45 +19,42 @@ The Kubernetes project has a well-documented [deprecation policy](/docs/referenc
Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the documentation.
## A Note About PodSecurityPolicy
## A note about PodSecurityPolicy {#podsecuritypolicy-removal}
In Kubernetes v1.25, we will be removing PodSecurityPolicy [after its deprecation in v1.21](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). PodSecurityPolicy has served us honorably, but its complex and often confusing usage necessitated changes, which unfortunately would have been breaking changes. To address this, it is being removed in favor of a replacement, Pod Security Admission, which is graduating to stable in this release as well. If you are currently relying on PodSecurityPolicy, follow the instructions for [migration to Pod Security Admission](/docs/tasks/configure-pod-container/migrate-from-psp/).
## Major Changes for Kubernetes v1.25
Kubernetes v1.25 includes several major changes, in addition to the removal of PodSecurityPolicy.
Kubernetes v1.25 will include several major changes, in addition to the removal of PodSecurityPolicy.
### [CSI Migration](https://github.com/kubernetes/enhancements/issues/625)
The effort to move the in-tree volume plugins to out-of-tree CSI drivers continues, with the core CSI Migration feature going GA in v1.25. This is an important step towards removing the in-tree volume plugins entirely.
### Volume Plugin Deprecations and Removals
### Deprecations and removals for storage drivers
Several volume are being deprecated or removed.
Several volume plugins are being deprecated or removed.
[GlusterFS will be deprecated in v1.25](https://github.com/kubernetes/enhancements/issues/3446). While a CSI driver was built for it, it has not been maintained. The possibility of migration to a compatible CSI driver [was discussed](https://github.com/kubernetes/kubernetes/issues/100897), but a decision was ultimately made to begin the deprecation of the GlusterFS plugin from in-tree drivers. The [Portworx in-tree volume plugin](https://github.com/kubernetes/enhancements/issues/2589) is also being deprecated with this release. The Flocker, Quobyte, and StorageOS in-tree volume plugins are being removed.
### [Declare Unsupported vSphere Versions](https://github.com/kubernetes/kubernetes/pull/111255)
[Flocker](https://github.com/kubernetes/kubernetes/pull/111618), [Quobyte](https://github.com/kubernetes/kubernetes/pull/111619), and [StorageOS](https://github.com/kubernetes/kubernetes/pull/111620) in-tree volume plugins will be removed in v1.25 as part of the [CSI Migration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/625-csi-migration).
From Kubernetes v1.25, the in-tree vSphere volume driver will not support any vSphere release before 7.0u2. Check the v1.25 detailed release notes for more advice on how to handle this.
### [Change to vSphere version support](https://github.com/kubernetes/kubernetes/pull/111255)
### [Signing Release Artifacts](https://github.com/kubernetes/enhancements/issues/3031)
An additional step in improving the security posture of the release process, the signing of Kubernetes release artifacts will graduate to Beta in this release. This is in line with the proposed enhancement of targeting SLSA Level 3 compliance for the Kubernetes release process.
### [Support for cgroup v2 Graduating to Stable](https://github.com/kubernetes/enhancements/issues/2254)
The new kernel cgroups v2 API was declared stable more than two years ago, and in this release we're taking solid steps towards full adoption of it. While cgroup v1 will continue to be supported, this change makes us ready to deal with the eventual deprecation of cgroup v1 and its replacement by cgroup v2.
From Kubernetes v1.25, the in-tree vSphere volume driver will not support any vSphere release before 7.0u2. Once Kubernetes v1.25 is released, check the v1.25 detailed release notes for more advice on how to handle this.
### [Cleaning up IPTables Chain Ownership](https://github.com/kubernetes/enhancements/issues/3178)
From the Kubernetes 1.25 release, the iptables chains created by Kubernetes will only support for internal Kubernetes use cases. Starting with v1.25, the Kubelet will gradually move towards not creating the following iptables chains in the `nat` table:
On Linux, Kubernetes (usually) creates iptables chains to ensure that network packets reach
Although these chains and their names have been an internal implementation detail, some tooling
has relied upon that behavior.
will only support for internal Kubernetes use cases. Starting with v1.25, the Kubelet will gradually move towards not creating the following iptables chains in the `nat` table:
- `KUBE-MARK-DROP`
- `KUBE-MARK-MASQ`
- `KUBE-POSTROUTING`
This change will be phased in via the `IPTablesCleanup` feature gate.
This change will be phased in via the `IPTablesCleanup` feature gate. Although this is not formally a deprecation, some end users have come to rely on specific internal behavior of `kube-proxy`. The Kubernetes project overall wants to make it clear that depending on these internal details is not supported, and that future implementations will change their behavior here.
## Looking ahead

55
content/en/blog/_posts/2022-08-11-enhancing-kubernetes-one-kep-at-a-time/index.md Normal file
View File

@ -0,0 +1,55 @@
---
layout: blog
title: "Enhancing Kubernetes one KEP at a Time"
date: 2022-08-11
slug: enhancing-kubernetes-one-kep-at-a-time
canonicalUrl: https://www.k8s.dev/blog/2022/08/11/enhancing-kubernetes-one-kep-at-a-time/
---
**Author:** Ryler Hockenbury (Mastercard)
Did you know that Kubernetes v1.24 has [46 enhancements](https://kubernetes.io/blog/2022/05/03/kubernetes-1-24-release-announcement/)? That's a lot of new functionality packed into a 4-month release cycle. The Kubernetes release team coordinates the logistics of the release, from remediating test flakes to publishing updated docs. It's a ton of work, but they always deliver.
The release team comprises around 30 people across six subteams - Bug Triage, CI Signal, Enhancements, Release Notes, Communications, and Docs.  Each of these subteams manages a component of the release. This post will focus on the role of the enhancements subteam and how you can get involved.
## What's the enhancements subteam?
Great question. We'll get to that in a second but first, let's talk about how features are managed in Kubernetes.
Each new feature requires a [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/README.md) - KEP for short. KEPs are small structured design documents that provide a way to propose and coordinate new features. The KEP author describes the motivation, design (and alternatives), risks, and tests - then community members provide feedback to build consensus.
KEPs are submitted and updated through a pull request (PR) workflow on the [k/enhancements repo](https://github.com/kubernetes/enhancements). Features start in alpha and move through a graduation process to beta and stable as they mature. For example, here's a cool KEP about [privileged container support on Windows Server](https://github.com/kubernetes/enhancements/blob/master/keps/sig-windows/1981-windows-privileged-container-support/kep.yaml).  It was introduced as alpha in Kubernetes v1.22 and graduated to beta in v1.23.
Now getting back to the question - the enhancements subteam coordinates the lifecycle tracking of the KEPs for each release. Each KEP is required to meet a set of requirements to be cleared for inclusion in a release. The enhancements subteam verifies each requirement for each KEP and tracks the status.
At the start of a release, [Kubernetes Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) submit their enhancements to opt into a release. A typical release might have from 60 to 90 enhancements at the beginning.  During the release, many enhancements will drop out. Some do not quite meet the KEP requirements, and others do not complete their implementation in code. About 60%-70% of the opted-in KEPs will make it into the final release.
## What does the enhancements subteam do?
Another great question, keep them coming! The enhancements team is involved in two crucial milestones during each release: enhancements freeze and code freeze.
#### Enhancements Freeze
Enhancements freeze is the deadline for a KEP to be complete in order for the enhancement to be included in a release. It's a quality gate to enforce alignment around maintaining and updating KEPs. The most notable requirements are a (1) [production readiness review ](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md)(PRR) and a (2) [KEP file](https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template) with a complete test plan and graduation criteria.
The enhancements subteam communicates to each KEP author through comments on the KEP issue on Github. As a first step, they'll verify the status and check if it meets the requirements.  The KEP gets marked as tracked after satisfying the requirements; otherwise, it's considered at risk. If a KEP is still at risk when enhancement freeze is in effect, the KEP is removed from the release.
This part of the cycle is typically the busiest for the enhancements subteam because of the large number of KEPs to groom, and each KEP might need to be visited multiple times to verify whether it meets requirements.
#### Code Freeze
Code freeze is the implementation deadline for all enhancements. The code must be implemented, reviewed, and merged by this point if a code change or update is needed for the enhancement. The latter third of the release is focused on stabilizing the codebase - fixing flaky tests, resolving various regressions, and preparing docs - and all the code needs to be in place before those steps can happen.
The enhancements subteam verifies that all PRs for an enhancement are merged into the [Kubernetes codebase](https://github.com/kubernetes/kubernetes) (k/k). During this period, the subteam reaches out to KEP authors to understand what PRs are part of the KEP, verifies that those PRs get merged, and then updates the status of the KEP. The enhancement is removed from the release if the code isn't all merged before the code freeze deadline.
## How can I get involved with the release team?
I'm glad you asked. The most direct way is to apply to be a [release team shadow](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). The shadow role is a hands-on apprenticeship intended to prepare individuals for leadership positions on the release team. Many shadow roles are non-technical and do not require prior contributions to the Kubernetes codebase.
With 3 Kubernetes releases every year and roughly 25 shadows per release, the release team is always in need of individuals wanting to contribute. Before each release cycle, the release team opens the application for the shadow program. When the application goes live, it's posted in the [Kubernetes Dev Mailing List](https://groups.google.com/a/kubernetes.io/g/dev).  You can subscribe to notifications from that list (or check it regularly!) to watch when the application opens. The announcement will typically go out in mid-April, mid-July, and mid-December - or roughly a month before the start of each release.
## How can I find out more?
Check out the [role handbooks](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks) if you're curious about the specifics of all the Kubernetes release subteams. The handbooks capture the logistics of each subteam, including a week-by-week breakdown of the subteam activities.  It's an excellent reference for getting to know each team better.
You can also check out the release-related Kubernetes slack channels - particularly #release, #sig-release, and #sig-arch. These channels have discussions and updates surrounding many aspects of the release.

70
content/en/blog/_posts/2022-08-15-meet-our-contributors-APAC-China-region-03.md Normal file
View File

@ -0,0 +1,70 @@
---
layout: blog
title: "Meet Our Contributors - APAC (China region)"
date: 2022-08-15
slug: meet-our-contributors-china-ep-03
canonicalUrl: https://www.kubernetes.dev/blog/2022/08/15/meet-our-contributors-chn-ep-03/
---
**Authors & Interviewers:** [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Priyanka Saggu](https://github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
---
Hello, everyone 👋
Welcome back to the third edition of the "Meet Our Contributors" blog post series for APAC.
This post features four outstanding contributors from China, who have played diverse leadership and community roles in the upstream Kubernetes project.
So, without further ado, let's get straight to the article.
## [Andy Zhang](https://github.com/andyzhangx)
Andy Zhang currently works for Microsoft China at the Shanghai site. His main focus is on Kubernetes storage drivers. Andy started contributing to Kubernetes about 5 years ago.
He states that as he is working in Azure Kubernetes Service team and spends most of his time contributing to the Kubernetes community project. Now he is the main contributor of quite a lot Kubernetes subprojects such as Kubernetes cloud provider code.
His open source contributions are mainly self-motivated. In the last two years he has mentored a few students contributing to Kubernetes through the LFX Mentorship program, some of whom got jobs due to their expertise and contributions on Kubernetes projects.
Andy is an active member of the China Kubernetes community. He adds that the Kubernetes community has a good guide about how to become members, code reviewers, approvers and finally when he found out that some open source projects are in the very early stage, he actively contributed to those projects and became the project maintainer.
## [Shiming Zhang](https://github.com/wzshiming)
Shiming Zhang is a Software Engineer working on Kubernetes for DaoCloud in Shanghai, China.
He has mostly been involved with SIG Node as a reviewer. His major contributions have mainly been bug fixes and feature improvements in an ongoing [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2712-pod-priority-based-graceful-node-shutdown), all revolving around SIG Node.
Some of his major PRs are [fixing watchForLockfileContention memory leak](https://github.com/kubernetes/kubernetes/pull/100326), [fixing startupProbe behaviour](https://github.com/kubernetes/kubernetes/pull/101093), [adding Field status.hostIPs for Pod](https://github.com/kubernetes/enhancements/pull/2661).
## [Paco Xu](https://github.com/pacoxu)
Paco Xu works at DaoCloud, a Shanghai-based cloud-native firm. He works with the infra and the open source team, focusing on enterprise cloud native platforms based on Kubernetes.
He started with Kubernetes in early 2017 and his first contribution was in March 2018. He started with a bug that he found, but his solution was not that graceful, hence wasn't accepted. He then started with some good first issues, which helped him to a great extent. In addition to this, from 2016 to 2017, he made some minor contributions to Docker.
Currently, Paco is a reviewer for `kubeadm` (a SIG Cluster Lifecycle product), and for SIG Node.
Paco says that you should contribute to open source projects you use. For him, an open source project is like a book to learn, getting inspired through discussions with the project maintainers.
> In my opinion, the best way for me is learning how owners work on the project.
## [Jintao Zhang](https://github.com/tao12345666333)
Jintao Zhang is presently employed at API7, where he focuses on ingress and service mesh.
In 2017, he encountered an issue which led to a community discussion and his contributions to Kubernetes started. Before contributing to Kubernetes, Jintao was a long-time contributor to Docker-related open source projects.
Currently Jintao is a reviewer for the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) project.
He suggests keeping track of job opportunities at open source companies so that you can find one that allows you to contribute full time. For new contributors Jintao says that if anyone wants to make a significant contribution to an open source project, then they should choose the project based on their interests and should generously invest time.
---
If you have any recommendations/suggestions for who we should interview next, please let us know in the [#sig-contribex channel](https://kubernetes.slack.com/archives/C1TU9EB9S) channel on the Kubernetes Slack. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.
We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋

2
content/en/docs/concepts/architecture/garbage-collection.md
View File

@ -8,7 +8,7 @@ weight: 50
{{<glossary_definition term_id="garbage-collection" length="short">}} This
allows the clean up of resources like the following:
* [Failed pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
* [Terminated pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
* [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
* [Objects without owner references](#owners-dependents)
* [Unused containers and container images](#containers-images)

4
content/en/docs/concepts/cluster-administration/addons.md
View File

@ -9,7 +9,7 @@ content_type: concept
Add-ons extend the functionality of Kubernetes.
This page lists some of the available add-ons and links to their respective installation instructions.
This page lists some of the available add-ons and links to their respective installation instructions. The list does not try to be exhaustive.
<!-- body -->
@ -27,7 +27,7 @@ This page lists some of the available add-ons and links to their respective inst
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking.
* [Nodus](https://github.com/akraino-edge-stack/icn-nodus) is an OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC).
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring.
* [Romana](https://github.com/romana) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy](/docs/concepts/services-networking/network-policies/) API.

49
content/en/docs/concepts/cluster-administration/flow-control.md
View File

@ -31,10 +31,13 @@ use informers and react to failures of API requests with exponential
back-off, and other clients that also work this way.
{{< caution >}}
Requests classified as "long-running" — primarily watches — are not
subject to the API Priority and Fairness filter. This is also true for
the `--max-requests-inflight` flag without the API Priority and
Fairness feature enabled.
Some requests classified as "long-running"&mdash;such as remote
command execution or log tailing&mdash;are not subject to the API
Priority and Fairness filter. This is also true for the
`--max-requests-inflight` flag without the API Priority and Fairness
feature enabled. API Priority and Fairness _does_ apply to **watch**
requests. When API Priority and Fairness is disabled, **watch** requests
are not subject to the `--max-requests-inflight` limit.
{{< /caution >}}
<!-- body -->
@ -93,6 +96,44 @@ Pods. This means that an ill-behaved Pod that floods the API server with
requests cannot prevent leader election or actions by the built-in controllers
from succeeding.
### Seats Occupied by a Request
The above description of concurrency management is the baseline story.
In it, requests have different durations but are counted equally at
any given moment when comparing against a priority level's concurrency
limit. In the baseline story, each request occupies one unit of
concurrency. The word "seat" is used to mean one unit of concurrency,
inspired by the way each passenger on a train or aircraft takes up one
of the fixed supply of seats.
But some requests take up more than one seat. Some of these are **list**
requests that the server estimates will return a large number of
objects. These have been found to put an exceptionally heavy burden
on the server, among requests that take a similar amount of time to
run. For this reason, the server estimates the number of objects that
will be returned and considers the request to take a number of seats
that is proportional to that estimated number.
### Execution time tweaks for watch requests
API Priority and Fairness manages **watch** requests, but this involves a
couple more excursions from the baseline behavior. The first concerns
how long a **watch** request is considered to occupy its seat. Depending
on request parameters, the response to a **watch** request may or may not
begin with **create** notifications for all the relevant pre-existing
objects. API Priority and Fairness considers a **watch** request to be
done with its seat once that initial burst of notifications, if any,
is over.
The normal notifications are sent in a concurrent burst to all
relevant **watch** response streams whenever the server is notified of an
object create/update/delete. To account for this work, API Priority
and Fairness considers every write request to spend some additional
time occupying seats after the actual writing is done. The server
estimates the number of notifications to be sent and adjusts the write
request's number of seats and seat occupancy time to include this
extra work.
### Queuing
Even within a priority level there may be a large number of distinct sources of

167
content/en/docs/concepts/cluster-administration/networking.md
View File

@ -32,172 +32,11 @@ different approach.
To learn about the Kubernetes networking model, see [here](/docs/concepts/services-networking/).
## How to implement the Kubernetes networking model
## How to implement the Kubernetes network model
There are a number of ways that this network model can be implemented. This
document is not an exhaustive study of the various methods, but hopefully serves
as an introduction to various technologies and serves as a jumping-off point.
The network model is implemented by the container runtime on each node. The most common container runtimes use [Container Network Interface](https://github.com/containernetworking/cni) (CNI) plugins to manage their network and security capabilities. Many different CNI plugins exist from many different vendors. Some of these provide only basic features of adding and removing network interfaces, while others provide more sophisticated solutions, such as integration with other container orchestration systems, running multiple CNI plugins, advanced IPAM features etc.
The following networking options are sorted alphabetically - the order does not
imply any preferential status.
{{% 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. [ACI](https://www.github.com/noironetworks/aci-containers) provides container networking integration for ACI. An overview of the integration is provided [here](https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf).
### Antrea
Project [Antrea](https://github.com/vmware-tanzu/antrea) is an opensource Kubernetes networking solution intended to be Kubernetes native. It leverages Open vSwitch as the networking data plane. Open vSwitch is a high-performance programmable virtual switch that supports both Linux and Windows. Open vSwitch enables Antrea to implement Kubernetes Network Policies in a high-performance and efficient manner.
Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to implement an extensive set of networking and security features and services on top of Open vSwitch.
### AWS VPC CNI for Kubernetes
The [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) offers integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. This CNI plugin offers high throughput and availability, low latency, and minimal network jitter. Additionally, users can apply existing AWS VPC networking and security best practices for building Kubernetes clusters. This includes the ability to use VPC flow logs, VPC routing policies, and security groups for network traffic isolation.
Using this CNI plugin allows Kubernetes pods to have the same IP address inside the pod as they do on the VPC network. The CNI allocates AWS Elastic Networking Interfaces (ENIs) to each Kubernetes node and using the secondary IP range from each ENI for pods on the node. The CNI includes controls for pre-allocation of ENIs and IP addresses for fast pod startup times and enables large clusters of up to 2,000 nodes.
Additionally, the CNI can be run alongside [Calico for network policy enforcement](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). The AWS VPC CNI project is open source with [documentation on GitHub](https://github.com/aws/amazon-vpc-cni-k8s).
### Azure CNI for Kubernetes
[Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) is an [open source](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) plugin that integrates Kubernetes Pods with an Azure Virtual Network (also known as VNet) providing network performance at par with VMs. Pods can connect to peered VNet and to on-premises over Express Route or site-to-site VPN and are also directly reachable from these networks. Pods can access Azure services, such as storage and SQL, that are protected by Service Endpoints or Private Link. You can use VNet security policies and routing to filter Pod traffic. The plugin assigns VNet IPs to Pods by utilizing a pool of secondary IPs pre-configured on the Network Interface of a Kubernetes node.
Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni).
### Calico
[Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement.
### Cilium
[Cilium](https://github.com/cilium/cilium) is open source software for
providing and transparently securing network connectivity between application
containers. Cilium is L7/HTTP aware and can enforce network policies on L3-L7
using an identity based security model that is decoupled from network
addressing, and it can be used in combination with other CNI plugins.
### CNI-Genie from Huawei
[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
### cni-ipvlan-vpc-k8s
[cni-ipvlan-vpc-k8s](https://github.com/lyft/cni-ipvlan-vpc-k8s) contains a set
of CNI and IPAM plugins to provide a simple, host-local, low latency, high
throughput, and compliant networking stack for Kubernetes within Amazon Virtual
Private Cloud (VPC) environments by making use of Amazon Elastic Network
Interfaces (ENI) and binding AWS-managed IPs into Pods using the Linux kernel's
IPvlan driver in L2 mode.
The plugins are designed to be straightforward to configure and deploy within a
VPC. Kubelets boot and then self-configure and scale their IP usage as needed
without requiring the often recommended complexities of administering overlay
networks, BGP, disabling source/destination checks, or adjusting VPC route
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) is a CNI plugin designed for ease of integration, providing flexible egress networking.
Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
### Contiv-VPP
[Contiv-VPP](https://contivpp.io/) is a user-space, performance-oriented network plugin for
Kubernetes, using the [fd.io](https://fd.io/) data plane.
### Contrail / Tungsten Fabric
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
### DANM
[DANM](https://github.com/nokia/danm) is a networking solution for telco workloads running in a Kubernetes cluster. It's built up from the following components:
* A CNI plugin capable of provisioning IPVLAN interfaces with advanced features
* An in-built IPAM module with the capability of managing multiple, cluster-wide, discontinuous L3 networks and provide a dynamic, static, or no IP allocation scheme on-demand
* A CNI metaplugin capable of attaching multiple network interfaces to a container, either through its own CNI, or through delegating the job to any of the popular CNI solution like SRI-OV, or Flannel in parallel
* A Kubernetes controller capable of centrally managing both VxLAN and VLAN interfaces of all Kubernetes hosts
* Another Kubernetes controller extending Kubernetes' Service-based service discovery concept to work over all network interfaces of a Pod
With this toolset DANM is able to provide multiple separated network interfaces, the possibility to use different networking back ends and advanced IPAM features for the pods.
### Flannel
[Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay
network that satisfies the Kubernetes requirements. Many
people have reported success with Flannel and Kubernetes.
### Hybridnet
[Hybridnet](https://github.com/alibaba/hybridnet) is an open source CNI plugin designed for hybrid clouds which provides both overlay and underlay networking for containers in one or more clusters. Overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity.
### Jaguar
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
### k-vswitch
[k-vswitch](https://github.com/k-vswitch/k-vswitch) is a simple Kubernetes networking plugin based on [Open vSwitch](https://www.openvswitch.org/). It leverages existing functionality in Open vSwitch to provide a robust networking plugin that is easy-to-operate, performant and secure.
### Knitter
[Knitter](https://github.com/ZTE/Knitter/) is a network solution which supports multiple networking in Kubernetes. It provides the ability of tenant management and network management. Knitter includes a set of end-to-end NFV container networking solutions besides multiple network planes, such as keeping IP address for applications, IP address migration, etc.
### Kube-OVN
[Kube-OVN](https://github.com/alauda/kube-ovn) is an OVN-based kubernetes network fabric for enterprises. With the help of OVN/OVS, it provides some advanced overlay network features like subnet, QoS, static IP allocation, traffic mirroring, gateway, openflow-based network policy and service proxy.
### Kube-router
[Kube-router](https://github.com/cloudnativelabs/kube-router) is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. Kube-router provides a Linux [LVS/IPVS](https://www.linuxvirtualserver.org/software/ipvs.html)-based service proxy, a Linux kernel forwarding-based pod-to-pod networking solution with no overlays, and iptables/ipset-based network policy enforcer.
### L2 networks and linux bridging
If you have a "dumb" L2 network, such as a simple switch in a "bare-metal"
environment, you should be able to do something similar to the above GCE setup.
Note that these instructions have only been tried very casually - it seems to
work, but has not been thoroughly tested. If you use this technique and
perfect the process, please let us know.
Follow the "With Linux Bridge devices" section of
[this very nice tutorial](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/) from
Lars Kellogg-Stedman.
### Multus (a Multi Network plugin)
Multus is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin)
[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking
### NSX-T
[VMware NSX-T](https://docs.vmware.com/en/VMware-NSX-T/index.html) is a network virtualization and security platform. NSX-T can provide network virtualization for a multi-cloud and multi-hypervisor environment and is focused on emerging application frameworks and architectures that have heterogeneous endpoints and technology stacks. In addition to vSphere hypervisors, these environments include other hypervisors such as KVM, containers, and bare metal.
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
### OVN (Open Virtual Networking)
OVN is an opensource network virtualization solution developed by the
Open vSwitch community. It lets one create logical switches, logical routers,
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).
### Weave Net from Weaveworks
[Weave Net](https://www.weave.works/oss/net/) is a
resilient and simple to use network for Kubernetes and its hosted applications.
Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
or stand-alone. In either version, it doesn't require any configuration or extra code
to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes.
See [this page](/docs/concepts/cluster-administration/addons/#networking-and-network-policy) for a non-exhaustive list of networking addons supported by Kubernetes.
## {{% heading "whatsnext" %}}

4
content/en/docs/concepts/cluster-administration/proxies.md
View File

@ -23,7 +23,7 @@ There are several different proxies you may encounter when using Kubernetes:
- locates apiserver
- adds authentication headers
1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services):
- is a bastion built into the apiserver
- connects a user outside of the cluster to cluster IPs which otherwise might not be reachable
@ -56,7 +56,7 @@ There are several different proxies you may encounter when using Kubernetes:
- implementation varies by cloud provider.
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
will typically ensure that the latter types are setup correctly.
will typically ensure that the latter types are set up correctly.
## Requesting redirects

2
content/en/docs/concepts/configuration/secret.md
View File

@ -1324,7 +1324,7 @@ have access to run a Pod that then exposes the Secret.
[RBAC](/docs/reference/access-authn-authz/rbac/).
- In the API server, objects (including Secrets) are persisted into
{{< glossary_tooltip term_id="etcd" >}}; therefore:
- only allow cluster admistrators to access etcd (this includes read-only access);
- only allow cluster administrators to access etcd (this includes read-only access);
- enable [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/)
for Secret objects, so that the data of these Secrets are not stored in the clear
into {{< glossary_tooltip term_id="etcd" >}};

2
content/en/docs/concepts/containers/container-lifecycle-hooks.md
View File

@ -105,7 +105,7 @@ The logs for a Hook handler are not exposed in Pod events.
If a handler fails for some reason, it broadcasts an event.
For `PostStart`, this is the `FailedPostStartHook` event,
and for `PreStop`, this is the `FailedPreStopHook` event.
To generate a failed `FailedPreStopHook` event yourself, modify the [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) file to change the postStart command to "badcommand" and apply it.
To generate a failed `FailedPostStartHook` event yourself, modify the [lifecycle-events.yaml](https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/lifecycle-events.yaml) file to change the postStart command to "badcommand" and apply it.
Here is some example output of the resulting events you see from running `kubectl describe pod lifecycle-demo`:
```

7
content/en/docs/concepts/containers/images.md
View File

@ -162,7 +162,7 @@ Credentials can be provided in several ways:
- requires node configuration by cluster administrator
- Pre-pulled Images
- all pods can use any images cached on a node
- requires root access to all nodes to setup
- requires root access to all nodes to set up
- Specifying ImagePullSecrets on a Pod
- only pods which provide own keys can access the private registry
- Vendor-specific or local extensions
@ -275,6 +275,8 @@ in private registries.
{{< /note >}}
Kubernetes supports specifying container image registry keys on a Pod.
`imagePullSecrets` must all be in the same namespace as the Pod. The referenced
Secrets must be of type `kubernetes.io/dockercfg` or `kubernetes.io/dockerconfigjson`.
#### Creating a Secret with a Docker config
@ -303,7 +305,8 @@ so this process needs to be done one time per namespace.
#### Referring to an imagePullSecrets on a Pod
Now, you can create pods which reference that secret by adding an `imagePullSecrets`
section to a Pod definition.
section to a Pod definition. Each item in the `imagePullSecrets` array can only
reference a Secret in the same namespace.
For example:

40
content/en/docs/concepts/extend-kubernetes/operator.md
View File

@ -15,13 +15,13 @@ Kubernetes principles, notably the [control loop](/docs/concepts/architecture/co
## Motivation
The Operator pattern aims to capture the key aim of a human operator who
The _operator pattern_ aims to capture the key aim of a human operator who
is managing a service or set of services. Human operators who look after
specific applications and services have deep knowledge of how the system
ought to behave, how to deploy it, and how to react if there are problems.
People who run workloads on Kubernetes often like to use automation to take
care of repeatable tasks. The Operator pattern captures how you can write
care of repeatable tasks. The operator pattern captures how you can write
code to automate a task beyond what Kubernetes itself provides.
## Operators in Kubernetes
@ -35,7 +35,7 @@ Kubernetes' {{< glossary_tooltip text="operator pattern" term_id="operator-patte
Operators are clients of the Kubernetes API that act as controllers for
a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
## An example Operator {#example}
## An example operator {#example}
Some of the things that you can use an operator to automate include:
@ -49,7 +49,7 @@ Some of the things that you can use an operator to automate include:
* choosing a leader for a distributed application without an internal
member election process
What might an Operator look like in more detail? Here's an example:
What might an operator look like in more detail? Here's an example:
1. A custom resource named SampleDB, that you can configure into the cluster.
2. A Deployment that makes sure a Pod is running that contains the
@ -57,36 +57,36 @@ What might an Operator look like in more detail? Here's an example:
3. A container image of the operator code.
4. Controller code that queries the control plane to find out what SampleDB
resources are configured.
5. The core of the Operator is code to tell the API server how to make
5. The core of the operator is code to tell the API server how to make
reality match the configured resources.
* If you add a new SampleDB, the operator sets up PersistentVolumeClaims
to provide durable database storage, a StatefulSet to run SampleDB and
a Job to handle initial configuration.
* If you delete it, the Operator takes a snapshot, then makes sure that
* If you delete it, the operator takes a snapshot, then makes sure that
the StatefulSet and Volumes are also removed.
6. The operator also manages regular database backups. For each SampleDB
resource, the operator determines when to create a Pod that can connect
to the database and take backups. These Pods would rely on a ConfigMap
and / or a Secret that has database connection details and credentials.
7. Because the Operator aims to provide robust automation for the resource
7. Because the operator aims to provide robust automation for the resource
it manages, there would be additional supporting code. For this example,
code checks to see if the database is running an old version and, if so,
creates Job objects that upgrade it for you.
## Deploying Operators
## Deploying operators
The most common way to deploy an Operator is to add the
The most common way to deploy an operator is to add the
Custom Resource Definition and its associated Controller to your cluster.
The Controller will normally run outside of the
{{< glossary_tooltip text="control plane" term_id="control-plane" >}},
much as you would run any containerized application.
For example, you can run the controller in your cluster as a Deployment.
## Using an Operator {#using-operators}
## Using an operator {#using-operators}
Once you have an Operator deployed, you'd use it by adding, modifying or
deleting the kind of resource that the Operator uses. Following the above
example, you would set up a Deployment for the Operator itself, and then:
Once you have an operator deployed, you'd use it by adding, modifying or
deleting the kind of resource that the operator uses. Following the above
example, you would set up a Deployment for the operator itself, and then:
```shell
kubectl get SampleDB # find configured databases
@ -94,19 +94,19 @@ kubectl get SampleDB # find configured databases
kubectl edit SampleDB/example-database # manually change some settings
```
&hellip;and that's it! The Operator will take care of applying the changes
&hellip;and that's it! The operator will take care of applying the changes
as well as keeping the existing service in good shape.
## Writing your own Operator {#writing-operator}
## Writing your own operator {#writing-operator}
If there isn't an Operator in the ecosystem that implements the behavior you
If there isn't an operator in the ecosystem that implements the behavior you
want, you can code your own.
You also implement an Operator (that is, a Controller) using any language / runtime
You also implement an operator (that is, a Controller) using any language / runtime
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
Following are a few libraries and tools you can use to write your own cloud native
Operator.
operator.
{{% thirdparty-content %}}
@ -129,6 +129,6 @@ Operator.
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
* [Publish](https://operatorhub.io/) your operator for other people to use
* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern (this is an archived version of the original article).
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the operator pattern (this is an archived version of the original article).
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building operators

9
content/en/docs/concepts/overview/kubernetes-api.md
View File

@ -93,19 +93,22 @@ for the kube-apiserver component.
A discovery endpoint `/openapi/v3` is provided to see a list of all
group/versions available. This endpoint only returns JSON. These group/versions
are provided in the following format:
```json
```yaml
{
"paths": {
...
...,
"api/v1": {
"serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF"
},
"apis/admissionregistration.k8s.io/v1": {
"serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597"
},
...
....
}
}
```
<!-- for editors: intionally use yaml instead of json here, to prevent syntax highlight error. -->
The relative URLs are pointing to immutable OpenAPI descriptions, in
order to improve client-side caching. The proper HTTP caching headers

2
content/en/docs/concepts/services-networking/connect-applications-service.md
View File

@ -305,7 +305,7 @@ Noteworthy points about the nginx-secure-app manifest:
serves HTTP traffic on port 80 and HTTPS traffic on 443, and nginx Service
exposes both ports.
- Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`.
This is setup *before* the nginx server is started.
This is set up *before* the nginx server is started.
```shell
kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml

2
content/en/docs/concepts/services-networking/dns-pod-service.md
View File

@ -301,7 +301,7 @@ search ns1.svc.cluster-domain.example my.dns.search.suffix
options ndots:2 edns0
```
For IPv6 setup, search path and name server should be setup like this:
For IPv6 setup, search path and name server should be set up like this:
```shell
kubectl exec -it dns-example -- cat /etc/resolv.conf

4
content/en/docs/concepts/services-networking/endpoint-slices.md
View File

@ -108,7 +108,7 @@ Services will always have the `ready` condition set to `true`.
#### Serving
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`serving` is identical to the `ready` condition, except it does not account for terminating states.
Consumers of the EndpointSlice API should check this condition if they care about pod readiness while
@ -127,7 +127,7 @@ for terminating pods independent of the existing semantics for `ready`.
#### Terminating
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`Terminating` is a condition that indicates whether an endpoint is terminating.
For pods, this is any pod that has a deletion timestamp set.

2
content/en/docs/concepts/services-networking/service.md
View File

@ -637,7 +637,7 @@ to specify IP address ranges that kube-proxy should consider as local to this no
For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag,
kube-proxy only selects the loopback interface for NodePort Services.
The default for `--nodeport-addresses` is an empty list.
his means that kube-proxy should consider all available network interfaces for NodePort.
This means that kube-proxy should consider all available network interfaces for NodePort.
(That's also compatible with earlier Kubernetes releases).
If you want a specific port number, you can specify a value in the `nodePort`

2
content/en/docs/concepts/storage/storage-classes.md
View File

@ -539,7 +539,7 @@ The following examples use the VMware Cloud Provider (vCP) StorageClass provisio
persistent volume (virtual disk) is being created. The virtual disk is
distributed across the Virtual SAN datastore to meet the requirements.
You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html)
You can see [Storage Policy Based Management for dynamic provisioning of volumes](https://github.com/vmware-archive/vsphere-storage-for-kubernetes/blob/fa4c8b8ad46a85b6555d715dd9d27ff69839df53/documentation/policy-based-mgmt.md)
for more details on how to use storage policies for persistent volumes
management.

6
content/en/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -32,9 +32,9 @@ Users need to be aware of the following when using this feature:
* Cloning support is only available for dynamic provisioners.
* CSI drivers may or may not have implemented the volume cloning functionality.
* You can only clone a PVC when it exists in the same namespace as the destination PVC (source and destination must be in the same namespace).
* Cloning is only supported within the same Storage Class.
- Destination volume must be the same storage class as the source
- Default storage class can be used and storageClassName omitted in the spec
* Cloning is supported with a different Storage Class.
- Destination volume can be the same or a different storage class as the source.
- Default storage class can be used and storageClassName omitted in the spec.
* Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)

2
content/en/docs/concepts/storage/volumes.md
View File

@ -450,7 +450,7 @@ as a PersistentVolume; referencing the volume directly from a pod is not support
#### Manually provisioning a Regional PD PersistentVolume
Dynamic provisioning is possible using a
[StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce).
[StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce-pd).
Before creating a PersistentVolume, you must create the persistent disk:
```shell

2
content/en/docs/concepts/workloads/controllers/deployment.md
View File

@ -620,7 +620,7 @@ deployment.apps/nginx-deployment scaled
```
Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) is enabled
in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
in your cluster, you can set up an autoscaler for your Deployment and choose the minimum and maximum number of
Pods you want to run based on the CPU utilization of your existing Pods.
```shell

4
content/en/docs/concepts/workloads/pods/downward-api.md
View File

@ -22,7 +22,7 @@ inject the Pod's name into the well-known environment variable.
In Kubernetes, there are two ways to expose Pod and container fields to a running container:
* as [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
* as [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
* as [files in a `downwardAPI` volume](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
Together, these two ways of exposing Pod and container fields are called the
@ -127,5 +127,5 @@ calculation.
You can read about [`downwardAPI` volumes](/docs/concepts/storage/volumes/#downwardapi).
You can try using the downward API to expose container- or Pod-level information:
* as [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
* as [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
* as [files in `downwardAPI` volume](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)

2
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -503,7 +503,7 @@ If you need to force-delete Pods that are part of a StatefulSet, refer to the ta
documentation for
[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
### Garbage collection of failed Pods {#pod-garbage-collection}
### Garbage collection of terminated Pods {#pod-garbage-collection}
For failed Pods, the API objects remain in the cluster's API until a human or
{{< glossary_tooltip term_id="controller" text="controller" >}} process

2
content/en/docs/contribute/new-content/blogs-case-studies.md
View File

@ -91,7 +91,7 @@ To submit a blog post, follow these steps:
- Blog posts should be relevant to Kubernetes users.
- Topics related to participation in or results of Kubernetes SIGs activities are always on
topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/blog-guidelines.md#upstream-marketing-blog-guidelines)
topic (see the work in the [Upstream Marketing Team](https://github.com/kubernetes/community/blob/master/communication/marketing-team/storytelling-resources/blog-guidelines.md#upstream-marketing-blog-guidelines)
for support on these posts).
- The components of Kubernetes are purposely modular, so tools that use existing integration
points like CNI and CSI are on topic.

6
content/en/docs/contribute/style/hugo-shortcodes/index.md
View File

@ -194,12 +194,12 @@ The tab **name** in a `tabs` definition must be unique within a content page.
```go-text-template
{{</* tabs name="tab_with_code" >}}
{{{< tab name="Tab 1" codelang="bash" >}}
{{< tab name="Tab 1" codelang="bash" >}}
echo "This is tab 1."
{{< /tab >}}
{{< tab name="Tab 2" codelang="go" >}}
println "This is tab 2."
{{< /tab >}}}
{{< /tab >}}
{{< /tabs */>}}
```
@ -306,7 +306,6 @@ Add the shortcode:
before the item, or just below the heading for the specific item.
## Version strings
To generate a version string for inclusion in the documentation, you can choose from
@ -378,4 +377,3 @@ Renders to:
* Learn about [page content types](/docs/contribute/style/page-content-types/).
* Learn about [opening a pull request](/docs/contribute/new-content/open-a-pr/).
* Learn about [advanced contributing](/docs/contribute/advanced/).

123
content/en/docs/reference/access-authn-authz/admission-controllers.md
View File

@ -103,7 +103,8 @@ CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultI
{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
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.
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}
@ -185,33 +186,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.
### DenyEscalatingExec {#denyescalatingexec}
{{< feature-state for_k8s_version="v1.13" state="deprecated" >}}
This admission controller will deny exec and attach commands to pods that run with escalated privileges that
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.
Use of a policy-based admission plugin (like [`PodSecurity`](#podsecurity) 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.
Use of a policy-based admission plugin (like [PodSecurity](#podsecurity) 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
@ -225,6 +199,8 @@ Most users do not need this feature at all, and cluster admins should consider d
Clusters that do need to use this feature should consider using some custom policy to manage usage
of it.
This admission controller is disabled by default.
### EventRateLimit {#eventratelimit}
{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
@ -240,8 +216,8 @@ event requests. The cluster admin can specify event rate limits by:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: EventRateLimit
path: eventconfig.yaml
- name: EventRateLimit
path: eventconfig.yaml
...
```
@ -259,18 +235,20 @@ Below is a sample `eventconfig.yaml` for such a configuration:
apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
- type: Namespace
qps: 50
burst: 100
cacheSize: 2000
- type: User
qps: 10
burst: 50
- type: Namespace
qps: 50
burst: 100
cacheSize: 2000
- type: User
qps: 10
burst: 50
```
See the [EventRateLimit Config API (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)
for more details.
This admission controller is disabled by default.
### ExtendedResourceToleration {#extendedresourcetoleration}
This plug-in facilitates creation of dedicated nodes with extended resources.
@ -280,10 +258,14 @@ name as the key. This admission controller, if enabled, automatically
adds tolerations for such taints to pods requesting extended resources, so users don't have to manually
add these tolerations.
This admission controller is diabled by default.
### ImagePolicyWebhook {#imagepolicywebhook}
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
This admission controller is disabled by default.
#### Configuration File Format
ImagePolicyWebhook uses a configuration file to set options for the behavior of the backend.
@ -308,8 +290,8 @@ Reference the ImagePolicyWebhook configuration file from the file provided to th
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
path: imagepolicyconfig.yaml
- name: ImagePolicyWebhook
path: imagepolicyconfig.yaml
...
```
@ -319,14 +301,14 @@ Alternatively, you can embed the configuration directly in the file:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
configuration:
imagePolicy:
kubeConfigFile: <path-to-kubeconfig-file>
allowTTL: 50
denyTTL: 50
retryBackoff: 500
defaultAllow: true
- name: ImagePolicyWebhook
configuration:
imagePolicy:
kubeConfigFile: <path-to-kubeconfig-file>
allowTTL: 50
denyTTL: 50
retryBackoff: 500
defaultAllow: true
```
The ImagePolicyWebhook config file must reference a
@ -340,17 +322,17 @@ must contain the returned authorizer.
```yaml
# clusters refers to the remote service.
clusters:
- name: name-of-remote-imagepolicy-service
cluster:
certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.
- name: name-of-remote-imagepolicy-service
cluster:
certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
server: https://images.example.com/policy # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
client-key: /path/to/key.pem # key matching the cert
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook admission controller to use
client-key: /path/to/key.pem # key matching the cert
```
For additional HTTP configuration, refer to the
@ -445,6 +427,8 @@ In any case, the annotations are provided by the user and are not validated by K
This admission controller denies any pod that defines `AntiAffinity` topology key other than
`kubernetes.io/hostname` in `requiredDuringSchedulingRequiredDuringExecution`.
This admission controller is disabled by default.
### LimitRanger {#limitranger}
This admission controller will observe the incoming request and ensure that it does not violate
@ -591,7 +575,8 @@ If the admission controller doesn't support automatic labelling your PersistentV
may need to add the labels manually to prevent pods from mounting volumes from
a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent volumes has been taken over by
the {{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}.
Starting from 1.11, this admission controller is disabled by default.
This admission controller is disabled by default.
### PodNodeSelector {#podnodeselector}
@ -600,6 +585,8 @@ Starting from 1.11, this admission controller is disabled by default.
This admission controller defaults and limits what node selectors may be used within a namespace
by reading a namespace annotation and a global configuration.
This admission controller is disabled by default.
#### Configuration file format
`PodNodeSelector` uses a configuration file to set options for the behavior of the backend.
@ -661,16 +648,23 @@ admission plugin, which allows preventing pods from running on specifically tain
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
This admission controller acts on creation and modification of the pod and
This is the replacement for the deprecated [PodSecurityPolicy](#podsecuritypolicy) admission controller
defined in the next section. This admission controller acts on creation and modification of the pod and
determines if it should be admitted based on the requested security context and the
[Pod Security Standards](/docs/concepts/security/pod-security-standards/).
See the [Pod Security Admission documentation](/docs/concepts/security/pod-security-admission/)
for more information.
Versions of Kubernetes prior to 1.25 included an admission controller for
the beta `PodSecurityPolicy` API; the Pod Security admission controller
provides similar, but not identical, security enforcement.
### PodSecurityPolicy {#podsecuritypolicy}
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
This admission controller acts on creation and modification of the pod and determines if it should be admitted
based on the requested security context and the available Pod Security Policies.
See also the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) documentation
for more information.
### PodTolerationRestriction {#podtolerationrestriction}
@ -702,6 +696,8 @@ metadata:
scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
```
This admission controller is disabled by default.
### Priority {#priority}
The priority admission controller uses the `priorityClassName` field and populates the integer
@ -720,8 +716,6 @@ and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for
### RuntimeClass {#runtimeclass}
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
If you define a RuntimeClass with [Pod overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
configured, this admission controller checks incoming Pods.
When enabled, this admission controller rejects any Pod create requests
@ -766,8 +760,6 @@ for more detailed information.
### TaintNodesByCondition {#taintnodesbycondition}
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created
Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods
to be scheduled on new Nodes before their taints were updated to accurately reflect their reported
@ -786,8 +778,7 @@ webhooks or other validating admission controllers will permit the request to fi
If you disable the ValidatingAdmissionWebhook, you must also disable the
`ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1`
group/version via the `--runtime-config` flag (both are on by default in
versions 1.9 and later).
group/version via the `--runtime-config` flag.
## Is there a recommended set of admission controllers to use?

6
content/en/docs/reference/access-authn-authz/authentication.md
View File

@ -171,8 +171,10 @@ how to manage these tokens with `kubeadm`.
A service account is an automatically enabled authenticator that uses signed
bearer tokens to verify requests. The plugin takes two optional flags:
* `--service-account-key-file` A file containing a PEM encoded key for signing bearer tokens.
If unspecified, the API server's TLS private key will be used.
* `--service-account-key-file` File containing PEM-encoded x509 RSA or ECDSA
private or public keys, used to verify ServiceAccount tokens. The specified file
can contain multiple keys, and the flag can be specified multiple times with
different files. If unspecified, --tls-private-key-file is used.
* `--service-account-lookup` If enabled, tokens which are deleted from the API will be revoked.
Service accounts are usually created automatically by the API server and

1
content/en/docs/reference/access-authn-authz/rbac.md
View File

@ -927,7 +927,6 @@ When bootstrapping the first roles and role bindings, it is necessary for the in
To bootstrap initial roles and role bindings:
* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings.
* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization.
## Command-line utilities

4
content/en/docs/reference/command-line-tools-reference/kubelet.md
View File

@ -219,7 +219,7 @@ kubelet [flags]
<td colspan="2">--container-runtime-endpoint string</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">The endpoint of remote runtime service. Unix Domain SOckets are supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: <code>unix:///var/run/dockershim.sock</code>, <code>npipe:////./pipe/dockershim</code>.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">The endpoint of remote runtime service. Unix Domain Sockets are supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: <code>unix:///path/to/runtime.sock</code>, <code>npipe:////./pipe/runtime</code>.</td>
</tr>
<tr>
@ -1093,7 +1093,7 @@ WindowsHostProcessContainers=true|false (BETA - default=true)<br/>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.<br/>
Preferred values:
`TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`, `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA`, `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`, `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA`, `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`, `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`, `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256`, `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`, `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`, `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA`, `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`, `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305`, `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`, `TLS_RSA_WITH_AES_128_CBC_SHA`, `TLS_RSA_WITH_AES_128_GCM_SHA256`, `TLS_RSA_WITH_AES_256_CBC_SHA`, `TLS_RSA_WITH_AES_256_GCM_SHA384`<br/>
Insecure values:<br/>
Insecure values:
`TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`, `TLS_ECDHE_ECDSA_WITH_RC4_128_SHA`, `TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA`, `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`, `TLS_ECDHE_RSA_WITH_RC4_128_SHA`, `TLS_RSA_WITH_3DES_EDE_CBC_SHA`, `TLS_RSA_WITH_AES_128_CBC_SHA256`, `TLS_RSA_WITH_RC4_128_SHA`.<br/>
(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)
</tr>

2
content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md
View File

@ -1773,7 +1773,7 @@ Probe describes a health check to be performed against a container to determine
- **grpc.service** (string)
Service is the name of the service to place in the gRPC HealthCheckRequest (see https://github.com/grpc/grpc/blob/master/doc/health-checking.md).
Service is the name of the service to place in the gRPC HealthCheckRequest (see https://github.com/grpc/grpc/blob/master/doc/health-checking.md ).
If this is not specified, the default behavior is defined by gRPC.

17
content/en/docs/reference/labels-annotations-taints/_index.md
View File

@ -168,6 +168,23 @@ Used on: Pod
This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
which allows users to influence ReplicaSet downscaling order. The annotation parses into an `int32` type.
### cluster-autoscaler.kubernetes.io/enable-ds-eviction
Example: `cluster-autoscaler.kubernetes.io/enable-ds-eviction: "true"`
Used on: Pod
This annotation controls whether a DaemonSet pod should be evicted by a ClusterAutoscaler.
This annotation needs to be specified on DaemonSet pods in a DaemonSet manifest.
When this annotation is set to `"true"`, the ClusterAutoscaler is allowed to evict a DaemonSet Pod,
even if other rules would normally prevent that. To disallow the ClusterAutoscaler from evicting DaemonSet pods,
you can set this annotation to `"false"` for important DaemonSet pods.
If this annotation is not set, then the Cluster Autoscaler follows its overall behaviour (i.e evict the DaemonSets based on its configuration).
{{< note >}}
This annotation only impacts DaemonSet pods.
{{< /note >}}
### kubernetes.io/ingress-bandwidth
{{< note >}}

4
content/en/docs/reference/setup-tools/kubeadm/implementation-details.md
View File

@ -464,7 +464,7 @@ access the certificate signing API.
This is implemented by creating a ClusterRoleBinding named `kubeadm:kubelet-bootstrap` between the
group above and the default RBAC role `system:node-bootstrapper`.
#### Setup auto approval for new bootstrap tokens
#### Set up auto approval for new bootstrap tokens
Kubeadm ensures that the Bootstrap Token will get its CSR request automatically approved by the
csrapprover controller.
@ -477,7 +477,7 @@ The role `system:certificates.k8s.io:certificatesigningrequests:nodeclient` shou
well, granting POST permission to
`/apis/certificates.k8s.io/certificatesigningrequests/nodeclient`.
#### Setup nodes certificate rotation with auto approval
#### Set up nodes certificate rotation with auto approval
Kubeadm ensures that certificate rotation is enabled for nodes, and that new certificate request
for nodes will get its CSR request automatically approved by the csrapprover controller.

2
content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
View File

@ -269,7 +269,7 @@ in the kubeadm config file.
1. Follow these [instructions](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) to set up the etcd cluster.
1. Setup SSH as described [here](#manual-certs).
1. Set up SSH as described [here](#manual-certs).
1. Copy the following files from any etcd node in the cluster to the first control plane node:

6
content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
View File

@ -12,7 +12,7 @@ card:
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px"></img>
This page shows how to install the `kubeadm` toolbox.
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
## {{% heading "prerequisites" %}}
@ -89,7 +89,7 @@ The tables below include the known endpoints for supported operating systems:
{{< tabs name="container_runtime" >}}
{{% tab name="Linux" %}}
{{< table >}}
{{< table caption="Linux container runtimes" >}}
| Runtime | Path to Unix domain socket |
|------------------------------------|----------------------------------------------|
| containerd | `unix:///var/run/containerd/containerd.sock` |
@ -101,7 +101,7 @@ The tables below include the known endpoints for supported operating systems:
{{% tab name="Windows" %}}
{{< table >}}
{{< table caption="Windows container runtimes" >}}
| Runtime | Path to Windows named pipe |
|------------------------------------|----------------------------------------------|
| containerd | `npipe:////./pipe/containerd-containerd` |

4
content/en/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -18,7 +18,7 @@ Kubernetes CLI, `kubectl`.
To access a cluster, you need to know the location of the cluster and have credentials
to access it. Typically, this is automatically set-up when you work through
a [Getting started guide](/docs/setup/),
or someone else setup the cluster and provided you with credentials and a location.
or someone else set up the cluster and provided you with credentials and a location.
Check the location and credentials that kubectl knows about with this command:
@ -265,5 +265,5 @@ There are several different proxies you may encounter when using Kubernetes:
- implementation varies by cloud provider.
Kubernetes users will typically not need to worry about anything other than the first two types. The cluster admin
will typically ensure that the latter types are setup correctly.
will typically ensure that the latter types are set up correctly.

2
content/en/docs/tasks/administer-cluster/access-cluster-api.md
View File

@ -22,7 +22,7 @@ Kubernetes command-line tool, `kubectl`.
To access a cluster, you need to know the location of the cluster and have credentials
to access it. Typically, this is automatically set-up when you work through
a [Getting started guide](/docs/setup/),
or someone else setup the cluster and provided you with credentials and a location.
or someone else set up the cluster and provided you with credentials and a location.
Check the location and credentials that kubectl knows about with this command:

36
content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
View File

@ -2,6 +2,7 @@
reviewers:
- mml
- wojtek-t
- jpbetz
title: Operating etcd clusters for Kubernetes
content_type: task
---
@ -187,7 +188,21 @@ replace it with `member4=http://10.0.0.4`.
fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
```
2. Remove the failed member:
1. Do either of the following:
1. If each Kubernetes API server is configured to communicate with all etcd
members, remove the failed member from the `--etcd-servers` flag, then
restart each Kubernetes API server.
1. If each Kubernetes API server communicates with a single etcd member,
then stop the Kubernetes API server that communicates with the failed
etcd.
1. Stop the etcd server on the broken node. It is possible that other
clients besides the Kubernetes API server is causing traffic to etcd
and it is desirable to stop all traffic to prevent writes to the data
dir.
1. Remove the failed member:
```shell
etcdctl member remove 8211f1d0f64f3269
@ -199,7 +214,7 @@ replace it with `member4=http://10.0.0.4`.
Removed member 8211f1d0f64f3269 from cluster
```
3. Add the new member:
1. Add the new member:
```shell
etcdctl member add member4 --peer-urls=http://10.0.0.4:2380
@ -211,7 +226,7 @@ replace it with `member4=http://10.0.0.4`.
Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4
```
4. Start the newly added member on a machine with the IP `10.0.0.4`:
1. Start the newly added member on a machine with the IP `10.0.0.4`:
```shell
export ETCD_NAME="member4"
@ -220,13 +235,16 @@ replace it with `member4=http://10.0.0.4`.
etcd [flags]
```
5. Do either of the following:
1. Do either of the following:
1. Update the `--etcd-servers` flag for the Kubernetes API servers to make
Kubernetes aware of the configuration changes, then restart the
Kubernetes API servers.
2. Update the load balancer configuration if a load balancer is used in the
deployment.
1. If each Kubernetes API server is configured to communicate with all etcd
members, add the newly added member to the `--etcd-servers` flag, then
restart each Kubernetes API server.
1. If each Kubernetes API server communicates with a single etcd member,
start the Kubernetes API server that was stopped in step 2. Then
configure Kubernetes API server clients to again route requests to the
Kubernetes API server that was stopped. This can often be done by
configuring a load balancer.
For more information on cluster reconfiguration, see
[etcd reconfiguration documentation](https://etcd.io/docs/current/op-guide/runtime-configuration/#remove-a-member).

2
content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md
View File

@ -22,7 +22,7 @@ The [Container runtimes](/docs/setup/production-environment/container-runtimes)
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
The page also provides details on how to set up a number of different container runtimes with the
`systemd` driver by default.
## Configuring the kubelet cgroup driver

6
content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md
View File

@ -34,7 +34,7 @@ upgrade the control plane nodes before upgrading your Windows nodes.
```powershell
# replace {{< param "fullversion" >}} with your desired version
curl.exe -Lo <path-to-kubeadm.exe> https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe
curl.exe -Lo <path-to-kubeadm.exe> "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe"
```
### Drain the node
@ -68,7 +68,7 @@ upgrade the control plane nodes before upgrading your Windows nodes.
```powershell
stop-service kubelet
curl.exe -Lo <path-to-kubelet.exe> https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe
curl.exe -Lo <path-to-kubelet.exe> "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe"
restart-service kubelet
```
@ -76,7 +76,7 @@ upgrade the control plane nodes before upgrading your Windows nodes.
```powershell
stop-service kube-proxy
curl.exe -Lo <path-to-kube-proxy.exe> https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kube-proxy.exe
curl.exe -Lo <path-to-kube-proxy.exe> "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kube-proxy.exe"
restart-service kube-proxy
```

8
content/en/docs/tasks/administer-cluster/verify-signed-images.md
View File

@ -64,9 +64,9 @@ section.
For non-control plane images (
e.g. [conformance image](https://github.com/kubernetes/kubernetes/blob/master/test/conformance/image/README.md))
, signatures can also be verified at deploy time using
[cosigned](https://docs.sigstore.dev/cosign/kubernetes/#cosigned-admission-controller)
admission controller. To get started with `cosigned` here are a few helpful
[sigstore policy-controller](https://docs.sigstore.dev/policy-controller/overview)
admission controller. To get started with `policy-controller` here are a few helpful
resources:
* [Installation](https://github.com/sigstore/cosign#installation)
* [Configuration Options](https://github.com/sigstore/cosign/blob/main/USAGE.md#detailed-usage)
* [Installation](https://github.com/sigstore/helm-charts/tree/main/charts/policy-controller)
* [Configuration Options](https://github.com/sigstore/policy-controller/tree/main/config)

6
content/en/docs/tasks/debug/debug-cluster/crictl.md
View File

@ -257,7 +257,7 @@ deleted by the Kubelet.
"attempt": 1,
"uid": "hdishd83djaidwnduwk28bcsb"
},
"logDirectory": "/tmp",
"log_directory": "/tmp",
"linux": {
}
}
@ -293,10 +293,10 @@ deleted by the Kubelet.
```json
{
"metadata": {
"name": "nginx-sandbox",
"name": "busybox-sandbox",
"namespace": "default",
"attempt": 1,
"uid": "hdishd83djaidwnduwk28bcsb"
"uid": "aewi4aeThua7ooShohbo1phoj"
},
"log_directory": "/tmp",
"linux": {

2
content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
View File

@ -276,6 +276,6 @@ spec:
## {{% heading "whatsnext" %}}
* [Setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
* [Set up an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer.
* For a high level overview, see [Extending the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).
* Learn how to [Extend the Kubernetes API Using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/).

2
content/en/docs/tasks/extend-kubernetes/setup-extension-api-server.md
View File

@ -25,7 +25,7 @@ Setting up an extension API server to work with the aggregation layer allows the
<!-- steps -->
## Setup an extension api-server to work with the aggregation layer
## Set up an extension api-server to work with the aggregation layer
The following steps describe how to set up an extension-apiserver *at a high level*. These steps apply regardless if you're using YAML configs or using APIs. An attempt is made to specifically identify any differences between the two. For a concrete example of how they can be implemented using YAML configs, you can look at the [sample-apiserver](https://github.com/kubernetes/sample-apiserver/blob/master/README.md) in the Kubernetes repo.

2
content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
View File

@ -13,7 +13,7 @@ A `downwardAPI` volume can expose Pod fields and container fields.
In Kubernetes, there are two ways to expose Pod and container fields to a running container:
* [Environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
* [Environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
* Volume files, as explained in this task
Together, these two ways of exposing Pod and container fields are called the

2
content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md
View File

@ -104,7 +104,7 @@ Address: 10.0.147.152
# Your address will vary.
```
If Kube-DNS is not setup correctly, the previous step may not work for you.
If Kube-DNS is not set up correctly, the previous step may not work for you.
You can also find the service IP in an env var:
```

2
content/en/docs/tasks/job/indexed-parallel-processing-static.md
View File

@ -19,7 +19,7 @@ to identify which part of the overall task to work on.
The pod index is available in the {{< glossary_tooltip text="annotation" term_id="annotation" >}}
`batch.kubernetes.io/job-completion-index` as a string representing its
decimal value. In order for the containerized task process to obtain this index,
you can publish the value of the annotation using the [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
you can publish the value of the annotation using the [downward API](/docs/concepts/workloads/pods/downward-api/)
mechanism.
For convenience, the control plane automatically sets the downward API to
expose the index in the `JOB_COMPLETION_INDEX` environment variable.

15
content/en/docs/tasks/manage-kubernetes-objects/kustomization.md
View File

@ -86,20 +86,12 @@ metadata:
name: example-configmap-1-8mbdf7882g
```
To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. This can also be used to set values from local environment variables by omitting the `=` and the value.
{{< note >}}
It's recommended to use the local environment variable population functionality sparingly - an overlay with a patch is often more maintainable. Setting values from the environment may be useful when they cannot easily be predicted, such as a git SHA.
{{< /note >}}
Here is an example of generating a ConfigMap with a data item from a `.env` file:
To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.env` file:
```shell
# Create a .env file
# BAZ will be populated from the local environment variable $BAZ
cat <<EOF >.env
FOO=Bar
BAZ
EOF
cat <<EOF >./kustomization.yaml
@ -113,7 +105,7 @@ EOF
The generated ConfigMap can be examined with the following command:
```shell
BAZ=Qux kubectl kustomize ./
kubectl kustomize ./
```
The generated ConfigMap is:
@ -121,11 +113,10 @@ The generated ConfigMap is:
```yaml
apiVersion: v1
data:
BAZ: Qux
FOO: Bar
kind: ConfigMap
metadata:
name: example-configmap-1-892ghb99c8
name: example-configmap-1-42cfbf598f
```
{{< note >}}

40
content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
View File

@ -144,21 +144,24 @@ struct has a `patchStrategy` of `merge`:
type PodSpec struct {
...
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...`
...
}
```
You can also see the patch strategy in the
[OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
```json
```yaml
"io.k8s.api.core.v1.PodSpec": {
...
"containers": {
"description": "List of containers belonging to the pod. ...
},
"x-kubernetes-patch-merge-key": "name",
"x-kubernetes-patch-strategy": "merge"
},
...,
"containers": {
"description": "List of containers belonging to the pod. ...."
},
"x-kubernetes-patch-merge-key": "name",
"x-kubernetes-patch-strategy": "merge"
}
```
<!-- for editors: intionally use yaml instead of json here, to prevent syntax highlight error. -->
And you can see the patch strategy in the
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
@ -204,6 +207,8 @@ strategic merge patch uses the default patch strategy, which is `replace`.
type PodSpec struct {
...
Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"`
...
}
```
## Use a JSON merge patch to update a Deployment
@ -365,19 +370,24 @@ type DeploymentSpec struct {
...
// +patchStrategy=retainKeys
Strategy DeploymentStrategy `json:"strategy,omitempty" patchStrategy:"retainKeys" ...`
...
}
```
You can also see the `retainKeys` strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
```json
```yaml
"io.k8s.api.apps.v1.DeploymentSpec": {
...
"strategy": {
"$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
"description": "The deployment strategy to use to replace existing pods with new ones.",
"x-kubernetes-patch-strategy": "retainKeys"
},
...,
"strategy": {
"$ref": "#/definitions/io.k8s.api.apps.v1.DeploymentStrategy",
"description": "The deployment strategy to use to replace existing pods with new ones.",
"x-kubernetes-patch-strategy": "retainKeys"
},
....
}
```
<!-- for editors: intionally use yaml instead of json here, to prevent syntax highlight error. -->
And you can see the `retainKeys` strategy in the
[Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).

27
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -54,31 +54,8 @@ To learn how to deploy the Metrics Server, see the
## Run and expose php-apache server
To demonstrate a HorizontalPodAutoscaler, you will first make a custom container image that uses
the `php-apache` image from Docker Hub as its starting point. The `Dockerfile` is ready-made for you,
and has the following content:
```dockerfile
FROM php:5-apache
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
```
This code defines a simple `index.php` page that performs some CPU intensive computations,
in order to simulate load in your cluster.
```php
<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
$x += sqrt($x);
}
echo "OK!";
?>
```
Once you have made that container image, start a Deployment that runs a container using the
image you made, and expose it as a {{< glossary_tooltip term_id="service">}}
To demonstrate a HorizontalPodAutoscaler, you will first start a Deployment that runs a container using the
`hpa-example` image, and expose it as a {{< glossary_tooltip term_id="service">}}
using the following manifest:
{{< codenew file="application/php-apache.yaml" >}}

2
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
View File

@ -357,7 +357,7 @@ reference page.
## Configuring your cluster to provide signing
This page assumes that a signer is setup to serve the certificates API. The
This page assumes that a signer is set up to serve the certificates API. The
Kubernetes controller manager provides a default implementation of a signer. To
enable it, pass the `--cluster-signing-cert-file` and
`--cluster-signing-key-file` parameters to the controller manager with paths to

14
content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md
View File

@ -51,23 +51,11 @@ Configurations with a single API server will experience unavailability while the
kube-controller-manager being unable to accept a CA bundle.
{{< /note >}}
1. Update all Secrets that hold service account tokens to include both old and new CA certificates.
1. Wait for the controller manager to update `ca.crt` in the service account Secrets to include both old and new CA certificates.
If any Pods are started before new CA is used by API servers, the new Pods get this update and will trust both
old and new CAs.
```shell
base64_encoded_ca="$(base64 -w0 <path to file containing both old and new CAs>)"
for namespace in $(kubectl get namespace --no-headers -o name | cut -d / -f 2 ); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml | \
/bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}/" | \
kubectl apply -f -
done
done
```
1. Restart all pods using in-cluster configurations (for example: kube-proxy, CoreDNS, etc) so they can use the
updated certificate authority data from Secrets that link to ServiceAccounts.

8
content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
View File

@ -31,12 +31,12 @@ Reload your shell and verify that bash-completion is correctly installed by typi
You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
{{< tabs name="kubectl_bash_autocompletion" >}}
{{{< tab name="User" codelang="bash" >}}
{{< tab name="User" codelang="bash" >}}
echo 'source <(kubectl completion bash)' >>~/.bashrc
{{< /tab >}}
{{< tab name="System" codelang="bash" >}}
kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
{{< /tab >}}}
{{< /tab >}}
{{< /tabs >}}
If you have an alias for kubectl, you can extend shell completion to work with that alias:
@ -51,3 +51,7 @@ bash-completion sources all completion scripts in `/etc/bash_completion.d`.
{{< /note >}}
Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working.
To enable bash autocompletion in current session of shell, source the ~/.bashrc file:
```bash
source ~/.bashrc
```

2
content/en/docs/tutorials/security/apparmor.md
View File

@ -330,7 +330,7 @@ Note the pod status is Pending, with a helpful error message: `Pod Cannot enforc
### Setting up nodes with profiles
Kubernetes does not currently provide any native mechanisms for loading AppArmor profiles onto
nodes. There are lots of ways to setup the profiles though, such as:
nodes. There are lots of ways to set up the profiles though, such as:
* Through a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) that runs a Pod on each node to
ensure the correct profiles are loaded. An example implementation can be found

13
content/en/docs/tutorials/security/seccomp.md
View File

@ -56,7 +56,6 @@ run as `Unconfined`.
<!-- steps -->
## Download example seccomp profiles {#download-profiles}
The contents of these profiles will be explored later on, but for now go ahead
@ -64,15 +63,15 @@ and download them into a directory named `profiles/` so that they can be loaded
into the cluster.
{{< tabs name="tab_with_code" >}}
{{{< tab name="audit.json" >}}
{{< tab name="audit.json" >}}
{{< codenew file="pods/security/seccomp/profiles/audit.json" >}}
{{< /tab >}}
{{< tab name="violation.json" >}}
{{< codenew file="pods/security/seccomp/profiles/violation.json" >}}
{{< /tab >}}}
{{< /tab >}}
{{< tab name="fine-grained.json" >}}
{{< codenew file="pods/security/seccomp/profiles/fine-grained.json" >}}
{{< /tab >}}}
{{< /tab >}}
{{< /tabs >}}
Run these commands:
@ -90,10 +89,8 @@ You should see three profiles listed at the end of the final step:
audit.json fine-grained.json violation.json
```
## Create a local Kubernetes cluster with kind
For simplicity, [kind](https://kind.sigs.k8s.io/) can be used to create a single
node cluster with the seccomp profiles loaded. Kind runs Kubernetes in Docker,
so each node of the cluster is a container. This allows for files
@ -378,7 +375,7 @@ kubectl delete service audit-pod --wait
kubectl delete pod audit-pod --wait --now
```
## Create Pod with seccomp profile that causes violation
## Create Pod with a seccomp profile that causes violation
For demonstration, apply a profile to the Pod that does not allow for any
syscalls.
@ -417,7 +414,7 @@ Clean up that Pod before moving to the next section:
kubectl delete pod violation-pod --wait --now
```
## Create Pod with seccomp profile that only allows necessary syscalls
## Create Pod with a seccomp profile that only allows necessary syscalls
If you take a look at the `fine-grained.json` profile, you will notice some of the syscalls
seen in syslog of the first example where the profile set `"defaultAction":

2
content/en/examples/admin/cloud/ccm-example.yaml
View File

@ -1,4 +1,4 @@
# This is an example of how to setup cloud-controller-manager as a Daemonset in your cluster.
# This is an example of how to set up cloud-controller-manager as a Daemonset in your cluster.
# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master
# Note that this Daemonset will not work straight out of the box for your cloud, this is
# meant to be a guideline.

4
content/en/releases/_index.md
View File

@ -7,7 +7,7 @@ type: docs
<!-- overview -->
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support.
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support.
Kubernetes versions are expressed as **x.y.z**,
where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
@ -22,6 +22,6 @@ More information in the [version skew policy](/releases/version-skew-policy/) do
## Upcoming Release
Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew currentVersionAddMinor 1 >}}) for the upcoming **{{< skew currentVersionAddMinor 1 >}}** Kubernetes release!
Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release!
## Helpful Resources

18
content/en/releases/download.md
View File

@ -13,7 +13,7 @@ for multiple operating systems as well as hardware architectures.
## Container Images
All Kubernetes container images are deployed to the
[registry.k8s.io](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/)
[k8s.gcr.io](https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/GLOBAL)
container registry.
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
@ -24,11 +24,11 @@ signatures:
| Container Image | Supported Architectures |
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| [registry.k8s.io/kube-apiserver:{{< param "fullversion" >}}][0] | [amd64][0-amd64], [arm][0-arm], [arm64][0-arm64], [ppc64le][0-ppc64le], [s390x][0-s390x] |
| [registry.k8s.io/kube-controller-manager:{{< param "fullversion" >}}][1] | [amd64][1-amd64], [arm][1-arm], [arm64][1-arm64], [ppc64le][1-ppc64le], [s390x][1-s390x] |
| [registry.k8s.io/kube-proxy:{{< param "fullversion" >}}][2] | [amd64][2-amd64], [arm][2-arm], [arm64][2-arm64], [ppc64le][2-ppc64le], [s390x][2-s390x] |
| [registry.k8s.io/kube-scheduler:{{< param "fullversion" >}}][3] | [amd64][3-amd64], [arm][3-arm], [arm64][3-arm64], [ppc64le][3-ppc64le], [s390x][3-s390x] |
| [registry.k8s.io/conformance:{{< param "fullversion" >}}][4] | [amd64][4-amd64], [arm][4-arm], [arm64][4-arm64], [ppc64le][4-ppc64le], [s390x][4-s390x] |
| [k8s.gcr.io/kube-apiserver:{{< param "fullversion" >}}][0] | [amd64][0-amd64], [arm][0-arm], [arm64][0-arm64], [ppc64le][0-ppc64le], [s390x][0-s390x] |
| [k8s.gcr.io/kube-controller-manager:{{< param "fullversion" >}}][1] | [amd64][1-amd64], [arm][1-arm], [arm64][1-arm64], [ppc64le][1-ppc64le], [s390x][1-s390x] |
| [k8s.gcr.io/kube-proxy:{{< param "fullversion" >}}][2] | [amd64][2-amd64], [arm][2-arm], [arm64][2-arm64], [ppc64le][2-ppc64le], [s390x][2-s390x] |
| [k8s.gcr.io/kube-scheduler:{{< param "fullversion" >}}][3] | [amd64][3-amd64], [arm][3-arm], [arm64][3-arm64], [ppc64le][3-ppc64le], [s390x][3-s390x] |
| [k8s.gcr.io/conformance:{{< param "fullversion" >}}][4] | [amd64][4-amd64], [arm][4-arm], [arm64][4-arm64], [ppc64le][4-ppc64le], [s390x][4-s390x] |
[0]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver
[0-amd64]: https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/kube-apiserver-amd64
@ -65,15 +65,15 @@ All container images are available for multiple architectures, whereas the
container runtime should choose the correct one based on the underlying
platform. It is also possible to pull a dedicated architecture by suffixing the
container image name, for example
[`registry.k8s.io/kube-apiserver-arm64:{{< param "fullversion" >}}`][0-arm64]. All
[`k8s.gcr.io/kube-apiserver-arm64:{{< param "fullversion" >}}`][0-arm64]. All
those derivations are signed in the same way as the multi-architecture manifest lists.
The Kubernetes project publishes a list of signed Kubernetes container images
in SBoM (Software Bill of Materials) format.
in [SPDX 2.2](https://spdx.dev/specifications/) format.
You can fetch that list using:
```shell
curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/latest.txt)/release" | awk '/PackageName: registry.k8s.io\// {print $2}'
curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/latest.txt)/release" | awk '/Package: registry.k8s.io\// {print $3}'
```
For Kubernetes v{{< skew currentVersion >}}, the only kind of code artifact that
you can verify integrity for is a container image, using the experimental

2
content/en/releases/version-skew-policy.md
View File

@ -23,7 +23,7 @@ Specific cluster deployment tools may place additional restrictions on version s
Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology.
For more information, see [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning).
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive [approximately 1 year of patch support](/releases/patch-releases/#support-period). Kubernetes 1.18 and older received approximately 9 months of patch support.
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
Patch releases are cut from those branches at a [regular cadence](/releases/patch-releases/#cadence), plus additional urgent releases, when required.

2
content/es/docs/concepts/configuration/secret.md
View File

@ -239,7 +239,7 @@ Las llaves de data y stringData deben consistir en caracteres alfanuméricos,
**Nota de codificación:** Los valores serializados JSON y YAML de los datos secretos estan codificadas como cadenas base64. Las nuevas lineas no son válidas dentro de esa cadena y debe ser omitido. Al usar `base64` en Darwin/macOS, los usuarios deben evitar el uso de la opción `-b` para dividir líneas largas. Por lo contratio los usuarios de Linux *deben* añadir la opción `-w 0` a los comandos `base64` o al pipeline `base64 | tr -d '\n'` si la opción `-w` no esta disponible.
#### Creaando un Secret a partir de Generador
#### Creando un Secret a partir de Generador
Kubectl soporta [managing objects using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/)
desde 1.14. Con esta nueva característica,
puedes tambien crear un Secret a partir de un generador y luego aplicarlo para crear el objeto en el Apiserver. Los generadores deben ser especificados en un `kustomization.yaml` dentro de un directorio.

6
content/es/docs/concepts/storage/volumes.md
View File

@ -1139,9 +1139,9 @@ Una vez que se despliega un controlador de volumen CSI compatible, los usuarios
Un volumen `csi` puede ser usado en un Pod en tres maneras distintas:
- a través de una referencia a [PersistentVolumeClaim](#persistentvolumeclaim)
- con un [volumen general efímero](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)
- con un [volumen general efímero](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)
(característica alpha)
- con un [volumen efímero CSI](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) si el controlador permite esta (característica beta)
- con un [volumen efímero CSI](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) si el controlador permite esta (característica beta)
Los siguientes campos están disponibles para que los administradores de almacenamiento configuren el volumen persistente CSI
@ -1168,7 +1168,7 @@ You can set up your [PersistentVolume/PersistentVolumeClaim with raw block volum
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
Puedes configurar directamente volúmenes CSI dentro de la especificación del Pod.
Los volúmenes especificados de esta manera son efímeros y no se persisten entre reinicios del Pod. Mira [Volúmenes efímeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) para más información.
Los volúmenes especificados de esta manera son efímeros y no se persisten entre reinicios del Pod. Mira [Volúmenes efímeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) para más información.
Para más información de cómo desarrollador un controlador CSI, mira la [documentación kubernetes-csi](https://kubernetes-csi.github.io/docs/)

2
content/es/docs/tasks/tools/included/install-kubectl-linux.md
View File

@ -132,7 +132,7 @@ Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Linux, es
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1

24
content/fr/docs/concepts/services-networking/service.md
View File

@ -56,7 +56,7 @@ Pour les applications non natives, Kubernetes propose des moyens de placer un po
Un service dans Kubernetes est un objet REST, semblable à un pod.
Comme tous les objets REST, vous pouvez effectuer un `POST` d'une définition de service sur le serveur API pour créer une nouvelle instance.
Par exemple, supposons que vous ayez un ensemble de pods qui écoutent chacun sur le port TCP 9376 et portent une étiquette `app=MyApp`:
Par exemple, supposons que vous ayez un ensemble de pods qui écoutent chacun sur le port TCP 9376 et portent une étiquette `app.kubernetes.io/name=MyApp`:
```yaml
apiVersion: v1
@ -65,14 +65,14 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
```
Cette spécification crée un nouvel objet Service nommé «my-service», qui cible le port TCP 9376 sur n'importe quel pod avec l'étiquette «app=MyApp».
Cette spécification crée un nouvel objet Service nommé «my-service», qui cible le port TCP 9376 sur n'importe quel pod avec l'étiquette «app.kubernetes.io/name=MyApp».
Kubernetes attribue à ce service une adresse IP (parfois appelé l'"IP cluster"), qui est utilisé par les proxies Service (voir [IP virtuelles et proxy de service](#virtual-ips-and-service-proxies)).
@ -254,7 +254,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
@ -414,7 +414,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
@ -518,7 +518,7 @@ metadata:
```yaml
[...]
metadata:
annotations:
annotations:
service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx
[...]
```
@ -740,13 +740,13 @@ Il existe d'autres annotations pour la gestion des équilibreurs de charge cloud
# ID d'un load balancer existant
service.kubernetes.io/tke-existed-lbid：lb-6swtxxxx
# Paramètres personnalisés pour le load balancer (LB), ne prend pas encore en charge la modification du type LB
service.kubernetes.io/service.extensiveParameters: ""
# Paramètres personnalisés pour le listener LB
# Paramètres personnalisés pour le listener LB
service.kubernetes.io/service.listenerParameters: ""
# Spécifie le type de Load balancer;
# valeurs valides: classic (Classic Cloud Load Balancer) ou application (Application Cloud Load Balancer)
service.kubernetes.io/loadbalance-type: xxxxx
@ -817,7 +817,7 @@ metadata:
name: my-service
spec:
selector:
app: MyApp
app.kubernetes.io/name: MyApp
ports:
- name: http
protocol: TCP
@ -952,7 +952,7 @@ suivi des données du client.
Kubernetes prend en charge SCTP en tant que valeur de «protocole» dans les définitions de Service, Endpoint, NetworkPolicy et Pod en tant que fonctionnalité alpha.
Pour activer cette fonction, l'administrateur du cluster doit activer le flag `SCTPSupport` sur l'apiserver, par exemple, `--feature-gates=SCTPSupport=true,…`.
When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`.
When the feature gate is enabled, you can set the `protocol` field of a Service, Endpoint, NetworkPolicy or Pod to `SCTP`.
Kubernetes sets up the network accordingly for the SCTP associations, just like it does for TCP connections.
#### Avertissements {#caveat-sctp-overview}

4
content/fr/docs/concepts/workloads/pods/init-containers.md
View File

@ -102,7 +102,7 @@ kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
app.kubernetes.io/name: MyApp
spec:
containers:
- name: myapp-container
@ -167,7 +167,7 @@ kubectl describe -f myapp.yaml
Name: myapp-pod
Namespace: default
[...]
Labels: app=myapp
Labels: app.kubernetes.io/name=MyApp
Status: Pending
[...]
Init Containers:

2
content/fr/includes/partner-script.js
View File

@ -509,7 +509,7 @@
name: 'Nirmata',
logo: 'nirmata',
link: 'https://www.nirmata.com/',
blurb: 'Nirmata - Nirmata Managed Kubernets'
blurb: 'Nirmata - Nirmata Managed Kubernetes'
},
{
type: 2,

4
content/ja/docs/concepts/containers/container-environment.md
View File

@ -29,12 +29,12 @@ Kubernetesはコンテナにいくつかの重要なリソースを提供しま
Podの名前と名前空間は[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)を通じて環境変数として利用可能です。
Pod定義からのユーザー定義の環境変数もコンテナで利用できます。
Dockerイメージで静的に指定されている環境変数も同様です。
コンテナイメージで静的に指定されている環境変数も同様です。
### クラスター情報
コンテナの作成時に実行されていたすべてのサービスのリストは、環境変数として使用できます。
これらの環境変数はDockerリンクの構文と一致します。
このリストは、新しいコンテナのPodおよびKubernetesコントロールプレーンサービスと同じ名前空間のサービスに制限されます。
*bar* という名前のコンテナに対応する *foo* という名前のサービスの場合、以下の変数が定義されています。

2
content/ja/docs/concepts/policy/limit-range.md
View File

@ -45,7 +45,7 @@ LimitRangeに対する競合や変更は、すでに作成済みのリソース
## {{% heading "whatsnext" %}}
より詳しい情報は、[LimitRangerの設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)を参照してください。
より詳しい情報は、[LimitRangerの設計ドキュメント](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)を参照してください。
制限の使用例については、以下のページを読んでください。

2
content/ja/docs/concepts/storage/persistent-volumes.md
View File

@ -746,7 +746,7 @@ spec:
* [Creating a Persistent Volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)について学ぶ
* [Creating a Persistent Volume Claim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)について学ぶ
* [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)を読む
* [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md)を読む
### リファレンス

58
content/ja/docs/concepts/storage/storage-limits.md Normal file
View File

@ -0,0 +1,58 @@
---
title: ノード固有のボリューム制限
content_type: concept
---
<!-- overview -->
このページでは、さまざまなクラウドプロバイダーのノードに接続できるボリュームの最大数について説明します。
通常、Google、Amazon、Microsoftなどのクラウドプロバイダーには、ノードに接続できるボリュームの数に制限があります。Kubernetesがこれらの制限を尊重することが重要です。
そうしないと、ノードでスケジュールされたPodが、ボリュームが接続されるのを待ってスタックする可能性があります。
<!-- body -->
## Kubernetesのデフォルトの制限
Kubernetesスケジューラーには、ノードに接続できるボリュームの数にデフォルトの制限があります。
<table>
<tr><th>クラウドサービス</th><th>ノード当たりの最大ボリューム</th></tr>
<tr><td><a href="https://aws.amazon.com/ebs/">Amazon Elastic Block Store (EBS)</a></td><td>39</td></tr>
<tr><td><a href="https://cloud.google.com/persistent-disk/">Google Persistent Disk</a></td><td>16</td></tr>
<tr><td><a href="https://azure.microsoft.com/en-us/services/storage/main-disks/">Microsoft Azure Disk Storage</a></td><td>16</td></tr>
</table>
## カスタム制限
これらの制限を変更するには、`KUBE_MAX_PD_VOLS`環境変数の値を設定し、スケジューラーを開始します。CSIドライバーの手順は異なる場合があります。制限をカスタマイズする方法については、CSIドライバーのドキュメントを参照してください。
デフォルトの制限よりも高い制限を設定する場合は注意してください。クラウドプロバイダーのドキュメントを参照して、設定した制限をノードが実際にサポートしていることを確認してください。
制限はクラスター全体に適用されるため、すべてのノードに影響します。
## 動的ボリューム制限
{{< feature-state state="stable" for_k8s_version="v1.17" >}}
動的ボリューム制限は、次のボリュームタイプでサポートされています。
- Amazon EBS
- Google Persistent Disk
- Azure Disk
- CSI
ツリー内のボリュームプラグインによって管理されるボリュームの場合、Kubernetesはノードタイプを自動的に決定し、ノードに適切なボリュームの最大数を適用します。例えば:
* <a href="https://cloud.google.com/compute/">Google Compute Engine</a>上では[ノードタイプ](https://cloud.google.com/compute/docs/disks/#pdnumberlimits)に応じて、最大127個のボリュームをノードに接続できます。
* M5、C5、R5、T3、およびZ1DインスタンスタイプのAmazon EBSディスクの場合、Kubernetesは25ボリュームのみをノードにアタッチできます。<a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>の他のインスタンスタイプの場合、Kubernetesでは39個のボリュームをノードに接続できます。
* Azureでは、ノードの種類に応じて、最大64個のディスクをノードに接続できます。詳細については、[Azureの仮想マシンのサイズ](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes)を参照してください。
* CSIストレージドライバーが(`NodeGetInfo`を使用して)ノードの最大ボリューム数をアドバタイズする場合、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}はその制限を尊重します。詳細については、[CSIの仕様](https://github.com/ontainer-storage-interface/spec/blob/master/spec.md#nodegetinfo)を参照してください。
* CSIドライバーに移行されたツリー内プラグインによって管理されるボリュームの場合、ボリュームの最大数はCSIドライバーによって報告される数になります。

2264
content/ja/docs/concepts/storage/volumes.md
View File

File diff suppressed because it is too large Load Diff

603
content/ja/docs/concepts/workloads/controllers/job.md Normal file
View File

@ -0,0 +1,603 @@
---
title: Jobs
content_type: concept
feature:
title: バッチ実行
description: >
サービスだけでなく、KubernetesはバッチとCIワークロードの管理機能も提供し、必要に応じて障害が発生したコンテナを置き換えることもできます。
weight: 50
---
<!-- overview -->
Jobは一つ以上のPodを作成し、指定された数のPodが正常に終了するまで、Podの実行を再試行し続けます。Podが正常に終了すると、Jobは成功したPodの数を追跡します。指定された完了数に達すると、そのタスク(つまりJob)は完了したとみなされます。Jobを削除すると、作成されたPodも一緒に削除されます。Jobを一時停止すると、再開されるまで、稼働しているPodは全部削除されます。
単純なケースを言うと、確実に一つのPodが正常に完了するまで実行されるよう、一つのJobオブジェクトを作成します。
一つ目のPodに障害が発生したり、(例えばノードのハードウェア障害またノードの再起動が原因で)削除されたりすると、Jobオブジェクトは新しいPodを作成します。
Jobで複数のPodを並列で実行することもできます。
スケジュールに沿ってJob(単一のタスクか複数タスク並列のいずれか)を実行したい場合は [CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。
<!-- body -->
## 実行例 {#running-an-example-job}
下記にJobの定義例を記載しています。πを2000桁まで計算して出力するJobで、完了するまで約10秒かかります。
{{< codenew file="controllers/job.yaml" >}}
このコマンドで実行できます:
```shell
kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml
```
実行結果はこのようになります:
```
job.batch/pi created
```
`kubectl`でJobの状態を確認できます:
{{< tabs name="Check status of Job" >}}
{{< tab name="kubectl describe job pi" codelang="bash" >}}
Name: pi
Namespace: default
Selector: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
job-name=pi
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
Parallelism: 1
Completions: 1
Start Time: Mon, 02 Dec 2019 15:20:11 +0200
Completed At: Mon, 02 Dec 2019 15:21:16 +0200
Duration: 65s
Pods Statuses: 0 Running / 1 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
job-name=pi
Containers:
pi:
Image: perl:5.34.0
Port: <none>
Host Port: <none>
Command:
perl
-Mbignum=bpi
-wle
print bpi(2000)
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 14m job-controller Created pod: pi-5rwd7
{{< /tab >}}
{{< tab name="kubectl get job pi -o yaml" codelang="bash" >}}
apiVersion: batch/v1
kind: Job
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":{"spec":{"containers":[{"command":["perl","-Mbignum=bpi","-wle","print bpi(2000)"],"image":"perl","name":"pi"}],"restartPolicy":"Never"}}}}
creationTimestamp: "2022-06-15T08:40:15Z"
generation: 1
labels:
controller-uid: 863452e6-270d-420e-9b94-53a54146c223
job-name: pi
name: pi
namespace: default
resourceVersion: "987"
uid: 863452e6-270d-420e-9b94-53a54146c223
spec:
backoffLimit: 4
completionMode: NonIndexed
completions: 1
parallelism: 1
selector:
matchLabels:
controller-uid: 863452e6-270d-420e-9b94-53a54146c223
suspend: false
template:
metadata:
creationTimestamp: null
labels:
controller-uid: 863452e6-270d-420e-9b94-53a54146c223
job-name: pi
spec:
containers:
- command:
- perl
- -Mbignum=bpi
- -wle
- print bpi(2000)
image: perl:5.34.0
imagePullPolicy: Always
name: pi
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Never
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
status:
active: 1
ready: 1
startTime: "2022-06-15T08:40:15Z"
{{< /tab >}}
{{< /tabs >}}
Jobの完了したPodを確認するには、`kubectl get pods`を使います。
Jobに属するPodの一覧を機械可読形式で出力するには、下記のコマンドを使います:
```shell
pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods
```
出力結果はこのようになります:
```
pi-5rwd7
```
ここのセレクターはJobのセレクターと同じです。`--output=jsonpath`オプションは、返されたリストからPodのnameフィールドを指定するための表現です。
その中の一つのPodの標準出力を確認するには:
```shell
kubectl logs $pods
```
出力結果はこのようになります:
```
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
```
## Job spec(仕様)の書き方 {#writing-a-job-spec}
他のKubernetesオブジェクト設定ファイルと同様に、Jobにも`apiVersion`、`kind`または`metadata`フィールドが必要です。
Jobの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。
Jobには[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。
### Podテンプレート {#pod-template}
`.spec.template`は`.spec`の唯一の必須フィールドです。
`.spec.template`は[podテンプレート](/ja/docs/concepts/workloads/pods/#pod-template)です。ネストされていることと`apiVersion`や`kind`フィールドが不要になったことを除いて、仕様の定義が{{< glossary_tooltip text="Pod" term_id="pod" >}}と全く同じです。
Podの必須フィールドに加えて、Job定義ファイルにあるPodテンプレートでは、適切なラベル([podセレクター](#pod-selector)を参照)と適切な再起動ポリシーを指定する必要があります。
[`RestartPolicy`](/ja/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)は`Never`か`OnFailure`のみ設定可能です。
### Podセレクター {#pod-selector}
`.spec.selector`フィールドはオプションです。ほとんどの場合はむしろ指定しないほうがよいです。
[独自のPodセレクターを指定](#specifying-your-own-pod-selector)セクションを参照してください。
### Jobの並列実行 {#parallel-jobs}
Jobで実行するのに適したタスクは主に3種類あります:
1. 非並列Job
- 通常、Podに障害が発生しない限り、一つのPodのみが起動されます。
- Podが正常に終了すると、Jobはすぐに完了します。
2. *固定の完了数*を持つ並列Job:
- `.spec.completions`に0以外の正の値を指定します。
- Jobは全体的なタスクを表し、`.spec.completions`個のPodが成功すると、Jobの完了となります。
- `.spec.completionMode="Indexed"`を利用する場合、各Podは0から`.spec.completions-1`までの範囲内のインデックスがアサインされます。
3. *ワークキュー*を利用した並列Job:
- `.spec.completions`の指定をしない場合、デフォルトは`.spec.parallelism`となります。
- Pod間で調整する、または外部サービスを使う方法で、それぞれ何のタスクに着手するかを決めます。例えば、一つのPodはワークキューから最大N個のタスクを一括で取得できます。
- 各Podは他のPodがすべて終了したかどうか、つまりJobが完了したかどうかを単独で判断できます。
- Jobに属する _任意_ のPodが正常に終了すると、新しいPodは作成されません。
- 一つ以上のPodが正常に終了し、すべてのPodが終了すると、Jobは正常に完了します。
- 一つのPodが正常に終了すると、他のPodは同じタスクの作業を行ったり、出力を書き込んだりすることはできません。すべてのPodが終了プロセスに進む必要があります。
_非並列_ Jobの場合、`.spec.completions`と`.spec.parallelism`の両方を未設定のままにしておくことも可能です。未設定の場合、両方がデフォルトで1になります。
_完了数固定_ Jobの場合、`.spec.completions`を必要完了数に設定する必要があります。
`.spec.parallelism`を設定してもいいですし、未設定の場合、デフォルトで1になります。
_ワークキュー_ 並列Jobの場合、`.spec.completions`を未設定のままにし、`.spec.parallelism`を非負の整数に設定する必要があります。
各種類のJobの使用方法の詳細については、[Jobパターン](#job-patterns)セクションを参照してください。
#### 並列処理の制御 {#controlling-parallelism}
必要並列数(`.spec.parallelism`)は任意の非負の値に設定できます。
未設定の場合は、デフォルトで1になります。
0に設定した際には、増加するまでJobは一時停止されます。
実際の並列数(任意の瞬間に実行されているPod数)は、さまざまな理由により、必要並列数と異なる可能性があります:
- _完了数固定_ Jobの場合、実際に並列して実行されるPodの数は、残りの完了数を超えることはありません。 `.spec.parallelism`の値が高い場合は無視されます。
- _ワークキュー_ Jobの場合、任意のPodが成功すると、新しいPodは作成されません。ただし、残りのPodは終了まで実行し続けられます。
- Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}の応答する時間がなかった場合。
- Jobコントローラーが何らかの理由で(`ResourceQuota`の不足、権限の不足など)、Podを作成できない場合、
実際の並列数は必要並列数より少なくなる可能性があります。
- 同じJobで過去に発生した過度のPod障害が原因で、Jobコントローラーは新しいPodの作成を抑制することがあります。
- Podがグレースフルシャットダウンされた場合、停止するのに時間がかかります。
### 完了モード {#completion-mode}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
_完了数固定_ Job、つまり`.spec.completions`の値がnullではないJobは`.spec.completionMode`で完了モードを指定できます:
- `NonIndexed`(デフォルト): `.spec.completions`個のPodが成功した場合、Jobの完了となります。言い換えれば、各Podの完了状態は同質です。ここで要注意なのは、`.spec.completions`の値がnullの場合、暗黙的に`NonIndexed`として指定されることです。
- `Indexed`: Jobに属するPodはそれぞれ、0から`.spec.completions-1`の範囲内の完了インデックスを取得できます。インデックスは下記の三つの方法で取得できます。
- Podアノテーション`batch.kubernetes.io/job-completion-index`。
- Podホスト名の一部として、`$(job-name)-$(index)`の形式になっています。
インデックス付きJob(Indexed Job)と{{< glossary_tooltip term_id="Service" >}}を一緒に使用すると、Jobに属するPodはお互いにDNSを介して確定的ホスト名で通信できます。
- コンテナ化されたタスクの環境変数`JOB_COMPLETION_INDEX`。
インデックスごとに、成功したPodが一つ存在すると、Jobの完了となります。完了モードの使用方法の詳細については、
[静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/)を参照してください。めったに発生しませんが、同じインデックスを取得して稼働し始めるPodも存在する可能性があります。ただし、完了数にカウントされるのはそのうちの一つだけです。
## Podとコンテナの障害対策 {#handling-pod-and-container-failures}
Pod内のコンテナは、その中のプロセスが0以外の終了コードで終了した、またはメモリ制限を超えたためにコンテナが強制終了されたなど、様々な理由で失敗することがあります。この場合、もし`.spec.template.spec.restartPolicy = "OnFailure"`と設定すると、Podはノード上に残りますが、コンテナは再実行されます。そのため、プログラムがローカルで再起動した場合の処理を行うか、`.spec.template.spec.restartPolicy = "Never"`と指定する必要があります。
`restartPolicy`の詳細については[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)を参照してください。
Podがノードからキックされた(ノードがアップグレード、再起動、削除されたなど)、または`.spec.template.spec.restartPolicy = "Never"`と設定されたときにPodに属するコンテナが失敗したなど、様々な理由でPod全体が故障することもあります。Podに障害が発生すると、Jobコントローラーは新しいPodを起動します。つまりアプリケーションは新しいPodで再起動された場合の処理を行う必要があります。特に、過去に実行した際に生じた一時ファイル、ロック、不完全な出力などを処理する必要があります。
`.spec.parallelism = 1`、`.spec.completions = 1`と`.spec.template.spec.restartPolicy = "Never"`を指定しても、同じプログラムが2回起動されることもありますので注意してください。
`.spec.parallelism`と`.spec.completions`を両方とも2以上指定した場合、複数のPodが同時に実行される可能性があります。そのため、Podは並行処理を行えるようにする必要があります。
### Pod失敗のバックオフポリシー {#pod-backoff-failure-policy}
設定の論理エラーなどにより、Jobが数回再試行した後に失敗状態にしたい場合があります。`.spec.backoffLimit`を設定すると、失敗したと判断するまでの再試行回数を指定できます。バックオフ制限はデフォルトで6に設定されています。Jobに属していて失敗したPodはJobコントローラーにより再作成され、バックオフ遅延は指数関数的に増加し(10秒、20秒、40秒…)、最大6分まで増加します。
再実行回数の算出方法は以下の2通りです:
- `.status.phase = "Failed"`で設定されたPod数を計算します。
- `restartPolicy = "OnFailure"`と設定された場合、`.status.phase`が`Pending`または`Running`であるPodに属するすべてのコンテナで再試行する回数を計算します。
どちらかの計算が`.spec.backoffLimit`に達した場合、Jobは失敗とみなされます。
[`JobTrackingWithFinalizers`](#job-tracking-with-finalizers)機能が無効な場合、
失敗したPodの数は、API内にまだ存在するPodのみに基づいています。
{{< note >}}
`restartPolicy = "OnFailure"`が設定されたJobはバックオフ制限に達すると、属するPodは全部終了されるので注意してください。これにより、Jobの実行ファイルのデバッグ作業が難しくなる可能性があります。失敗したJobからの出力が不用意に失われないように、Jobのデバッグ作業をする際は`restartPolicy = "Never"`を設定するか、ロギングシステムを使用することをお勧めします。
{{< /note >}}
## Jobの終了とクリーンアップ {#job-termination-and-cleanup}
Jobが完了すると、それ以上Podは作成されませんが、[通常](#pod-backoff-failure-policy)Podが削除されることもありません。
これらを残しておくと、完了したPodのログを確認でき、エラーや警告などの診断出力を確認できます。
またJobオブジェクトはJob完了後も残っているため、状態を確認することができます。古いJobの状態を把握した上で、削除するかどうかはユーザー次第です。Jobを削除するには`kubectl` (例:`kubectl delete jobs/pi`または`kubectl delete -f ./job.yaml`)を使います。`kubectl`でJobを削除する場合、Jobが作成したPodも全部削除されます。
デフォルトでは、Jobは中断されることなく実行できますが、Podが失敗した場合(`restartPolicy=Never`)、またはコンテナがエラーで終了した場合(`restartPolicy=OnFailure`)のみ、前述の`.spec.backoffLimit`で決まった回数まで再試行します。`.spec.backoffLimit`に達すると、Jobが失敗とマークされ、実行中のPodもすべて終了されます。
Jobを終了させるもう一つの方法は、活動期間を設定することです。
Jobの`.spec.activeDeadlineSeconds`フィールドに秒数を設定することで、活動期間を設定できます。
Podがいくつ作成されても、`activeDeadlineSeconds`はJobの存続する時間に適用されます。
Jobが`activeDeadlineSeconds`に達すると、実行中のすべてのPodは終了され、Jobの状態は`type: Failed`になり、理由は`reason: DeadlineExceeded`になります。
ここで要注意なのは、Jobの`.spec.activeDeadlineSeconds`は`.spec.backoffLimit`よりも優先されます。したがって、失敗して再試行しているPodが一つ以上持っているJobは、`backoffLimit`に達していなくても、`activeDeadlineSeconds`で指定された設定時間に達すると、追加のPodをデプロイしなくなります。
例えば:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi-with-timeout
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
Job仕様と、Jobに属する[Podテンプレートの仕様](/ja/docs/concepts/workloads/pods/init-containers/#detailed-behavior)は両方とも`activeDeadlineSeconds`フィールドを持っているので注意してください。適切なレベルで設定していることを確認してください。
また`restartPolicy`はJob自体ではなく、Podに適用されることも注意してください: Jobの状態は`type: Failed`になると、自動的に再起動されることはありません。
つまり、`.spec.activeDeadlineSeconds`と`.spec.backoffLimit`によって引き起こされるJob終了メカニズムは、永久的なJob失敗につながり、手動で介入して解決する必要があります。
## 終了したJobの自動クリーンアップ {#clean-up-finished-jobs-automatically}
終了したJobは通常システムに残す必要はありません。残ったままにしておくとAPIサーバーに負担をかけることになります。Jobが上位コントローラーにより直接管理されている場合、例えば[CronJobs](/ja/docs/concepts/workloads/controllers/cron-jobs/)の場合、Jobは指定された容量ベースのクリーンアップポリシーに基づき、CronJobによりクリーンアップされます。
### 終了したJobのTTLメカニズム {#ttl-mechanism-for-finished-jobs}
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
終了したJob(状態が`Complete`か`Failed`になったJob)を自動的にクリーンアップするもう一つの方法は
[TTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)より提供されたTTLメカニズムです。`.spec.ttlSecondsAfterFinished`フィールドを指定することで、終了したリソースをクリーンアップすることができます。
TTLコントローラーでJobをクリーンアップする場合、Jobはカスケード的に削除されます。つまりJobを削除する際に、Jobに属しているオブジェクト、例えばPodなども一緒に削除されます。Jobが削除される場合、Finalizerなどの、Jobのライフサイクル保証は守られることに注意してください。
例えば:
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: pi-with-ttl
spec:
ttlSecondsAfterFinished: 100
template:
spec:
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
Job `pi-with-ttl`は終了してからの`100`秒後に自動的に削除されるようになっています。
このフィールドに`0`を設定すると、Jobは終了後すぐに自動削除の対象になります。このフィールドに何も設定しないと、Jobが終了してもTTLコントローラーによるクリーンアップはされません。
{{< note >}}
`ttlSecondsAfterFinished`フィールドを設定することが推奨されます。管理されていないJob(CronJobなどの、他のワークロードAPIを経由せずに、直接作成したJob)は`orphanDependents`というデフォルトの削除ポリシーがあるため、Jobが完全に削除されても、属しているPodが残ってしまうからです。
{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}は最終的に、失敗または完了して削除されたJobに属するPodを[ガベージコレクション](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)しますが、Podが残っていると、クラスターのパフォーマンスが低下することがあり、最悪の場合、この低下によりクラスターがオフラインになることがあります。
[LimitRanges](/ja/docs/concepts/policy/limit-range/)と[リソースクォータ](/ja/docs/concepts/policy/resource-quotas/)で、指定する名前空間が消費できるリソースの量に上限を設定することができます。
{{< /note >}}
## Jobパターン {#job-patterns}
Jobオブジェクトは、Podの確実な並列実行をサポートするために使用されます。科学技術計算でよく見られるような、密接に通信を行う並列処理をサポートするようには設計されていません。独立だが関連性のある一連の*作業項目*の並列処理をサポートします。例えば送信すべき電子メール、レンダリングすべきフレーム、トランスコードすべきファイル、スキャンすべきNoSQLデータベースのキーの範囲、などです。
複雑なシステムでは、異なる作業項目のセットが複数存在する場合があります。ここでは、ユーザーが一斉に管理したい作業項目のセットが一つだけの場合 &mdash; つまり*バッチJob*だけを考えます。
並列計算にはいくつかのパターンがあり、それぞれに長所と短所があります。
トレードオフの関係にあるのは:
- 各作業項目に1つのJobオブジェクト vs. すべての作業項目に1つのJobオブジェクト。
　後者は大量の作業項目を処理する場合に適しています。
　前者は大量のJobオブジェクトを管理するため、ユーザーとシステムにオーバーヘッドをかけることになります。
- 作成されるPod数が作業項目数と等しい、 vs. 各Podが複数の作業項目を処理する。
　前者は通常、既存のコードやコンテナへの変更が少なくて済みます。
後者は上記と同じ理由で、大量の作業項目を処理する場合に適しています。
- ワークキューを利用するアプローチもいくつかあります。それを使うためには、キューサービスを実行し、既存のプログラムやコンテナにワークキューを利用させるための改造を行う必要があります。
他のアプローチは既存のコンテナ型アプリケーションに適用しやすいです。
ここでは、上記のトレードオフをまとめてあり、それぞれ2～4列目に対応しています。
またパターン名のところは、例やより詳しい説明が書いてあるページへのリンクになっています。
| パターン | 単一Jobオブジェクト | Podが作業項目より少ない？ | アプリを修正せずに使用できる？ |
| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|
| [作業項目ごとにPodを持つキュー] | ✓ | | 時々 |
| [Pod数可変のキュー] | ✓ | ✓ | |
| [静的な処理の割り当てを使用したインデックス付きJob] | ✓ | | ✓ |
| [Jobテンプレート拡張] | | | ✓ |
`.spec.completions`で完了数を指定する場合、Jobコントローラーより作成された各Podは同一の[`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)を持ちます。これは、このタスクのすべてのPodが同じコマンドライン、同じイメージ、同じボリューム、そして(ほぼ)同じ環境変数を持つことを意味します。これらのパターンは、Podが異なる作業をするためのさまざまな配置方法になります。
この表は、各パターンで必要な`.spec.parallelism`と`.spec.completions`の設定を示しています。
ここで、`W`は作業項目の数を表しています。
| パターン | `.spec.completions` | `.spec.parallelism` |
| ----------------------------------------- |:-------------------:|:--------------------:|
| [作業項目ごとにPodを持つキュー] | W | 任意 |
| [Pod数可変のキュー] | null | 任意 |
| [静的な処理の割り当てを使用したインデックス付きJob] | W | 任意 |
| [Jobテンプレート拡張] | 1 | 1であるべき |
[作業項目ごとにPodを持つキュー]: /docs/tasks/job/coarse-parallel-processing-work-queue/
[Pod数可変のキュー]: /docs/tasks/job/fine-parallel-processing-work-queue/
[静的な処理の割り当てを使用したインデックス付きJob]: /ja/docs/tasks/job/indexed-parallel-processing-static/
[Jobテンプレート拡張]: /docs/tasks/job/parallel-processing-expansion/
## 高度な使い方 {#advanced-usage}
### Jobの一時停止 {#suspending-a-job}
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
Jobが作成されると、JobコントローラーはJobの要件を満たすために直ちにPodの作成を開始し、Jobが完了するまで作成し続けます。しかし、Jobの実行を一時的に中断して後で再開したい場合、または一時停止状態のJobを再開し、再開時間は後でカスタムコントローラーに判断させたい場合はあると思います。
Jobを一時停止するには、Jobの`.spec.suspend`フィールドをtrueに修正し、後でまた再開したい場合にはfalseに修正すればよいです。
`.spec.suspend`をtrueに設定してJobを作成すると、一時停止状態のままで作成されます。
一時停止状態のJobを再開すると、`.status.startTime`フィールドの値は現在時刻にリセットされます。これはつまり、Jobが一時停止して再開すると、`.spec.activeDeadlineSeconds`タイマーは停止してリセットされることになります。
Jobを中断すると、稼働中のPodは全部削除されることを忘れないでください。Jobが中断されると、PodはSIGTERMシグナルを受信して[終了されます](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。Podのグレースフル終了の猶予期間がカウントダウンされ、この期間内に、Podはこのシグナルを処理しなければなりません。場合により、その後のために処理状況を保存したり、変更を元に戻したりする処理が含まれます。この方法で終了したPodは`completions`数にカウントされません。
下記は一時停止状態のままで作成されたJobの定義例になります:
```shell
kubectl get job myjob -o yaml
```
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
spec:
suspend: true
parallelism: 1
completions: 5
template:
spec:
...
```
Jobのstatusセクションで、Jobが停止中なのか、過去に停止したことがあるかを判断できます:
```shell
kubectl get jobs/myjob -o yaml
```
```yaml
apiVersion: batch/v1
kind: Job
# .metadata and .spec omitted
status:
conditions:
- lastProbeTime: "2021-02-05T13:14:33Z"
lastTransitionTime: "2021-02-05T13:14:33Z"
status: "True"
type: Suspended
startTime: "2021-02-05T13:13:48Z"
```
Jobのcondition.typeが"Suspended"で、statusが"True"になった場合、Jobは一時停止中になります。`lastTransitionTime`フィールドで、どのぐらい中断されたかを判断できます。statusが"False"になった場合、Jobは一時停止状態でしたが、今は実行されていることになります。conditionが書いていない場合、Jobは一度も停止していないことになります。
Jobが一時停止して再開した場合、Eventsも作成されます:
```shell
kubectl describe jobs/myjob
```
```
Name: myjob
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 12m job-controller Created pod: myjob-hlrpl
Normal SuccessfulDelete 11m job-controller Deleted pod: myjob-hlrpl
Normal Suspended 11m job-controller Job suspended
Normal SuccessfulCreate 3s job-controller Created pod: myjob-jvb44
Normal Resumed 3s job-controller Job resumed
```
最後の4つのイベント、特に"Suspended"と"Resumed"のイベントは、`.spec.suspend`フィールドの値を切り替えた直接の結果です。この2つのイベントの間に、Podは作成されていないことがわかりますが、Jobが再開されるとすぐにPodの作成も再開されました。
### 可変スケジューリング命令 {#mutable-scheduling-directives}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< note >}}
この機能を使うためには、[APIサーバー](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)上で`JobMutableNodeSchedulingDirectives`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
デフォルトで有効になっています。
{{< /note >}}
ほとんどの場合、並列Jobは、すべてのPodが同じゾーン、またはすべてのGPUモデルxかyのいずれかであるが、両方の混在ではない、などの制約付きで実行することが望ましいです。
[suspend](#suspending-a-job)フィールドは、これらの機能を実現するための第一歩です。Suspendは、カスタムキューコントローラーがJobをいつ開始すべきかを決定することができます。しかし、Jobの一時停止が解除されると、カスタムキューコントローラーは、Job内のPodの実際の配置場所には影響を与えません。
この機能により、Jobが開始される前にスケジューリング命令を更新でき、カスタムキューコントローラーがPodの配置に影響を与えることができると同時に、実際のPodとノードの割り当てをkube-schedulerにオフロードすることができます。これは一時停止されたJobの中で、一度も一時停止解除されたことのないJobに対してのみ許可されます。
JobのPodテンプレートで更新可能なフィールドはnodeAffinity、nodeSelector、tolerations、labelsとannotationsです。
### 独自のPodセレクターを指定 {#specifying-your-own-pod-selector}
Jobオブジェクトを作成する際には通常、`.spec.selector`を指定しません。Jobが作成された際に、システムのデフォルトロジックは、他のJobと重ならないようなセレクターの値を選択し、このフィールドに追加します。
しかし、場合によっては、この自動設定されたセレクターをオーバーライドする必要があります。そのためには、Jobの`.spec.selector`を指定します。
その際には十分な注意が必要です。そのJobの他のPodと重なったラベルセレクターを指定し、無関係のPodにマッチした場合、無関係のJobのPodが削除されたり、無関係のPodが完了されてもこのJobの完了数とカウントしたり、片方または両方のJobがPodの作成または完了までの実行を拒否する可能性があります。
一意でないセレクターを選択した場合、他のコントローラー(例えばReplicationController)や属しているPodが予測できない挙動をする可能性があります。Kubernetesは`.spec.selector`を間違って設定しても止めることはしません。
下記はこの機能の使用例を紹介しています。
`old`と名付けたJobがすでに実行されていると仮定します。既存のPodをそのまま実行し続けてほしい一方で、作成する残りのPodには別のテンプレートを使用し、そのJobには新しい名前を付けたいとしましょう。これらのフィールドは更新できないため、Jobを直接更新できません。そのため、`kubectl delete jobs/old --cascade=orphan`で、_属しているPodが実行されたまま_、`old`Jobを削除します。削除する前に、どのセレクターを使用しているかをメモしておきます:
```shell
kubectl get job old -o yaml
```
出力結果はこのようになります:
```yaml
kind: Job
metadata:
name: old
...
spec:
selector:
matchLabels:
controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
...
```
次に、`new`という名前で新しくJobを作成し、同じセレクターを明示的に指定します。既存のPodも`controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`ラベルが付いているので、同じく`new`Jobによってコントロールされます。
通常システムが自動的に生成するセレクターを使用しないため、新しいJobで `manualSelector: true`を指定する必要があります。
```yaml
kind: Job
metadata:
name: new
...
spec:
manualSelector: true
selector:
matchLabels:
controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002
...
```
新しいJobは`a8f3d00d-c6d2-11e5-9f87-42010af00002`ではなく、別のuidを持つことになります。`manualSelector: true`を設定することで、自分は何をしているかを知っていて、またこのミスマッチを許容することをシステムに伝えます。
### FinalizerによるJob追跡 {#job-tracking-with-finalizers}
{{< feature-state for_k8s_version="v1.23" state="beta" >}}
{{< note >}}
この機能を使うためには、[APIサーバー](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)で`JobTrackingWithFinalizers`
[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。
有効にした場合、コントロールプレーンは下記に示す機能で新しいJobを追跡します。この機能が有効になる前に作成されたJobは影響を受けません。ユーザーとして実感できる唯一の違いは、コントロールプレーンのJob完了ステータス追跡がより正確になるということだけです。
{{< /note >}}
この機能が有効でない場合、Job {{< glossary_tooltip term_id="controller" >}}はクラスター内に存在するPodを数えてJobステータスを追跡します。つまり`succeeded`Podと`failed`Podのカウンターを保持します。
しかし、Podは以下のような理由で削除されることもあります:
- Nodeがダウンしたときに、孤立した(Orphan)Podを削除するガベージコレクター。
- 閾値に達すると、(`Succeeded`または`Failed`フェーズで)終了したPodを削除するガベージコレクター。
- Jobに属するPodの人為的な削除。
- 外部コントローラー(Kubernetesの一部として提供されていない)によるPodの削除や置き換え。
クラスターで`JobTrackingWithFinalizers`機能を有効にすると、コントロールプレーンは任意のJobに属するPodを追跡し、そのようなPodがAPIサーバーから削除された場合に通知します。そのために、Jobコントローラーは`batch.kubernetes.io/job-tracking`Finalizerを持つPodを作成します。コントローラーはPodがJobステータスに計上された後にのみFinalizerを削除し、他のコントローラーやユーザーによるPodの削除を可能にします。
Jobコントローラーは、新しいJobに対してのみ新しいアルゴリズムを使用します。この機能が有効になる前に作成されたJobは影響を受けません。JobコントローラーがPod FinalizerでJob追跡しているかどうかは、Jobが`batch.kubernetes.io/job-tracking`というアノテーションを持っているかどうかで判断できます。
このアノテーションを手動で追加または削除しては**いけません**。
## 代替案 {#alternatives}
### 単なるPod {#bare-pods}
Podが動作しているノードが再起動または故障した場合、Podは終了し、再起動されません。しかし、終了したPodを置き換えるため、Jobが新しいPodを作成します。このため、たとえアプリケーションが1つのPodしか必要としない場合でも、単なるPodではなくJobを使用することをお勧めします。
### Replication Controller {#replication-controller}
Jobは[Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/)を補完するものです。
Replication Controllerは、終了することが想定されていないPod(Webサーバーなど)を管理し、Jobは終了することが想定されているPod(バッチタスクなど)を管理します。
[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)で説明したように、`Job`は`RestartPolicy`が`OnFailure`か`Never`と設定されているPodに*のみ*適用されます。(注意:`RestartPolicy`が設定されていない場合、デフォルト値は`Always`になります)
### シングルJobによるコントローラーPodの起動 {#single-job-starts-controller-pod}
もう一つのパターンは、一つのJobが一つPodを作り、そのPodがカスタムコントローラーのような役割を果たし、他のPodを作ります。これは最も柔軟性がありますが、使い始めるにはやや複雑で、Kubernetesとの統合もあまりできません。
このパターンの一例としては、Sparkマスターコントローラーを起動し、sparkドライバーを実行してクリーンアップするスクリプトを実行するPodをJobで起動する([sparkの例](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)を参照)が挙げられます。
この方法のメリットは、全処理過程でJobオブジェクトが完了する保証がありながらも、どのPodを作成し、どのように作業を割り当てるかを完全に制御できることです。
## {{% heading "whatsnext" %}}
* [Pods](/ja/docs/concepts/workloads/pods/)について学ぶ。
* Jobのさまざまな実行方法について学ぶ:
* [ワークキューを用いた粒度の粗い並列処理](/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [ワークキューを用いた粒度の細かい並列処理](/docs/tasks/job/fine-parallel-processing-work-queue/)
* [静的な処理の割り当てを使用した並列処理のためのインデックス付きJob](/ja/docs/tasks/job/indexed-parallel-processing-static/) を使う(beta段階)
* テンプレートを元に複数のJobを作成: [拡張機能を用いた並列処理](/docs/tasks/job/parallel-processing-expansion/)
* [終了したJobの自動クリーンアップ](#clean-up-finished-jobs-automatically)のリンクから、クラスターが完了または失敗したJobをどのようにクリーンアップするかをご確認ください。
* `Job`はKubernetes REST APIの一部です。JobのAPIを理解するために、{{< api-reference page="workload-resources/job-v1" >}}オブジェクトの定義をお読みください。
* UNIXツールの`cron`と同様に、スケジュールに基づいて実行される一連のJobを定義するために使用できる[`CronJob`](/ja/docs/concepts/workloads/controllers/cron-jobs/)についてお読みください。

2
content/ja/examples/controllers/job.yaml
View File

@ -7,7 +7,7 @@ spec:
spec:
containers:
- name: pi
image: perl
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4

2
content/ja/includes/task-tutorial-prereqs.md
View File

@ -3,5 +3,5 @@ Kubernetesクラスターが必要、かつそのクラスターと通信する
まだクラスターがない場合、[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)を使って作成するか、
以下のいずれかのKubernetesプレイグラウンドも使用できます:
* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)
* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes)
* [Play with Kubernetes](http://labs.play-with-k8s.com/)

10
content/ko/_index.html
View File

@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준
<button id="desktopShowVideoButton" onclick="kub.showVideo()">비디오 보기</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">KubeCon Europe (2022년 5월 17~20일) 참가하기</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">KubeCon North America (2022년 10월 24~28일) 참가하기</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2023/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu23" button id="desktopKCButton">KubeCon Europe (2023년 4월 17~21일) 참가하기</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

179
content/ko/blog/_posts/2022-05-13-grpc-probes-in-beta.md Normal file
View File

@ -0,0 +1,179 @@
---
layout: blog
title: "쿠버네티스 1.24: gRPC 컨테이너 프로브 베타"
date: 2022-05-13
slug: grpc-probes-now-in-beta
---
**저자**: Sergey Kanzhelev (Google)
**번역**: 송원석 (쏘카), 손석호 (ETRI), 김상홍 (국민대), 김보배 (11번가)
쿠버네티스 1.24에서 gRPC 프로브 기능이 베타에 진입했으며 기본적으로 사용 가능하다.
이제 HTTP 엔드포인트를 노출하지 않고, gRPC 앱에 대한 스타트업(startup), 활성(liveness) 및 준비성(readiness) 프로브를 구성할 수 있으며,
실행 파일도 필요하지 않는다. 쿠버네티스는 기본적으로 gRPC를 통해 워크로드에 자체적으로(natively) 연결 가능하며, 상태를 쿼리할 수 있다.
## 약간의 히스토리
시스템이 워크로드의 앱이 정상인지, 정상적으로 시작되었는지,
트래픽을 수용할 수 있는지에 대해 관리하는 것은 유용하다.
gRPC 지원이 추가되기 전에도, 쿠버네티스는 이미 컨테이너 이미지
내부에서 실행 파일을 실행하거나, HTTP 요청을 하거나,
TCP 연결이 성공했는지 여부를 확인하여 상태를 확인할 수 있었다.
대부분의 앱은, 이러한 검사로 충분하다. 앱이 상태(또는 준비성) 확인을
위한 gRPC 엔드포인트를 제공하는 경우 `exec` 프로브를
gRPC 상태 확인에 사용하도록 쉽게 용도를 변경할 수 있다.
블로그 기사 [쿠버네티스의 gRPC 서버 상태 확인](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)에서, Ahmet Alp Balkan은 이를 수행하는 방법을 설명하였으며, 이는 지금도 여전히 작동하는 메커니즘이다.
이것을 활성화하기 위해 일반적으로 사용하는 도구는 2018년 8월 21일에 [생성](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)되었으며, 이 도구의 첫 릴리즈는 [2018년 9월 19일](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1)에 나왔다.
gRPC 앱 상태 확인을 위한 이 접근 방식은 매우 인기있다. `grpc_health_probe`를 포함하고 있는 [Dockerfile은 3,626개](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)이며, (문서 작성 시점에)GitHub의 기본 검색으로 발견된 [yaml 파일은 6,621개](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code)가 있다. 이것은 도구의 인기와 이를 기본적으로 지원해야 할 필요성을 잘 나타낸다.
쿠버네티스 v1.23은 gRPC를 사용하여 워크로드 상태를 쿼리하는 기본(native) 지원을 알파 수준의 구현으로 기본 지원으로 도입 및 소개했다. 알파 기능이었기 때문에 v1.23 릴리스에서는 기본적으로 비활성화되었다.
## 기능 사용
우리는 다른 프로브와 유사한 방식으로 gRPC 상태를 확인할 수 있도록 구축했으며, 쿠버네티스의 다른 프로브에 익숙하다면 [사용하기 쉬울 것](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)이라 믿는다.
자체적으로 지원되는 상태 프로브는 `grpc_health_probe` 실행 파일과 관련되어 있던 차선책에 비해 많은 이점이 있다.
기본 gRPC 지원을 사용하면 이미지에 `10MB`의 추가 실행 파일을 다운로드하여 저장할 필요가 없다.
Exec 프로브는 실행 파일을 실행하기 위해 새 프로세스를 인스턴스화해야 하므로 일반적으로 gRPC 호출보다 느리다.
또한 파드가 리소스 최대치로 실행 중이고 새 프로세스를 인스턴스화하는데 문제가 있는 경우에는 검사의 분별성을 낮추게 만든다.
그러나 여기에는 몇 가지 제약이 있다. 프로브용 클라이언트 인증서(certificate)를 구성하는 것이 어렵기 때문에, 클라이언트 인증(authentication)이 필요한 서비스는 지원하지 않는다. 기본 제공(built-in) 프로브도 서버 인증서를 확인하지 않고 관련 문제를 무시한다.
또한 기본 제공 검사는 특정 유형의 오류를 무시하도록 구성할 수 없으며 (`grpc_health_probe`는 다른 오류에 대해 다른 종료 코드를 반환함), 단일 프로브에서 여러 서비스 상태 검사를 실행하도록 "연계(chained)"할 수 없다.
그러나 이러한 모든 제한 사항은 gRPC에서 꽤 일반적이며 이에 대한 쉬운 해결 방법이 있다.
## 직접 해 보기
### 클러스터 수준의 설정
오늘 이 기능을 사용해 볼 수 있다. 기본 gRPC 프로브 사용을 시도하려면, `GRPCContainerProbe` 기능 게이트를 활성화하여 쿠버네티스 클러스터를 직접 가동한다. [가용한 도구](/ko/docs/tasks/tools/)가 많이 있다.
기능 게이트 `GRPCContainerProbe`는 1.24에서 기본적으로 활성화되어 있으므로, 많은 공급업체가 이 기능을 즉시 사용 가능하도록 제공할 것이다.
따라서 선택한 플랫폼에서 1.24 클러스터를 그냥 생성하면 된다. 일부 공급업체는 1.23 클러스터에서 알파 기능을 사용 할 수 있도록 허용한다.
예를 들어, 빠른 테스트를 위해 GKE에서 테스트 클러스터를 가동할 수 있다. (해당 문서 작성 시점 기준)
다른 공급업체도 유사한 기능을 가지고 있을 수 있다. 특히 쿠버네티스 1.24 릴리스 이후 이 블로그 게시물을 읽고 있는 경우에는 더욱 그렇다.
GKE에서 다음 명령어를 사용한다. (참고로 버전은 `1.23`이고 `enable-kubernetes-alpha`가 지정됨).
```shell
gcloud container clusters create test-grpc \
--enable-kubernetes-alpha \
--no-enable-autorepair \
--no-enable-autoupgrade \
--release-channel=rapid \
--cluster-version=1.23
```
또한 클러스터에 접근하기 위해서 `kubectl`을 구성할 필요가 있다.
```shell
gcloud container clusters get-credentials test-grpc
```
### 기능 사용해 보기
gRPC 프로브가 작동하는 방식을 테스트하기 위해 파드를 생성해 보겠다. 이 테스트에서는 `agnhost` 이미지를 사용한다.
이것은 모든 종류의 워크로드 테스트에 사용할 수 있도록, k8s가 유지 관리하는 이미지다.
예를 들어, 두 개의 포트를 노출하는 유용한 [grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) 모듈을 가지고 있다. 하나는 상태 확인 서비스를 제공하고 다른 하나는 `make-serving` 및 `make-not-serving` 명령에 반응하는 http 포트다.
다음은 파드 정의의 예시이다. 이 예시는 `grpc-health-checking` 모듈을 시작하고, 포트 `5000` 및 `8080`을 노출하며, gRPC 준비성 프로브를 구성한다.
``` yaml
---
apiVersion: v1
kind: Pod
metadata:
name: test-grpc
spec:
containers:
- name: agnhost
image: k8s.gcr.io/e2e-test-images/agnhost:2.35
command: ["/agnhost", "grpc-health-checking"]
ports:
- containerPort: 5000
- containerPort: 8080
readinessProbe:
grpc:
port: 5000
```
`test.yaml`이라는 파일이 있으면, 파드를 생성하고 상태를 확인할 수 있다. 파드는 아래 출력 스니펫(snippet)에 표시된 대로 준비(ready) 상태가 된다.
```shell
kubectl apply -f test.yaml
kubectl describe test-grpc
```
출력에는 다음과 같은 내용이 포함된다.
```
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
```
이제 상태 확인 엔드포인트 상태를 NOT_SERVING으로 변경해 보겠다.
파드의 http 포트를 호출하기 위해 포트 포워드를 생성한다.
```shell
kubectl port-forward test-grpc 8080:8080
```
명령을 호출하기 위해 `curl`을 사용할 수 있다 ...
```shell
curl http://localhost:8080/make-not-serving
```
... 그리고 몇 초 후에 포트 상태가 준비되지 않음으로 전환된다.
```shell
kubectl describe pod test-grpc
```
이제 다음과 같은 출력을 확인할 수 있을 것이다.
```
Conditions:
Type Status
Initialized True
Ready False
ContainersReady False
PodScheduled True
...
Warning Unhealthy 2s (x6 over 42s) kubelet Readiness probe failed: service unhealthy (responded with "NOT_SERVING")
```
다시 전환되면, 약 1초 후에 파드가 준비(ready) 상태로 돌아간다.
``` bsh
curl http://localhost:8080/make-serving
kubectl describe test-grpc
```
아래 출력은 파드가 다시 `Ready` 상태로 돌아갔다는 것을 나타낸다.
```
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
```
쿠버네티스에 내장된 이 새로운 gRPC 상태 프로브를 사용하면 별도의 `exec` 프로브를 사용하는 이전 접근 방식보다 gRPC를 통한 상태 확인을 훨씬 쉽게 구현할 수 있다. 더 자세한 내용 파악을 위해 공식 [문서](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 자세히 살펴보고, 기능이 GA로 승격되기 전에 피드백을 제공하길 바란다.
## 요약
쿠버네티스는 인기 있는 워크로드 오케스트레이션 플랫폼이며 피드백과 수요를 기반으로 기능을 추가한다.
gRPC 프로브 지원과 같은 기능은 많은 앱 개발자의 삶을 더 쉽게 만들고 앱을 더 탄력적으로 만들 수 있는 마이너한 개선이다. 오늘 기능을 사용해보고 기능이 GA로 전환되기 전에 오늘 사용해 보고 피드백을 제공해보자.

4
content/ko/community/code-of-conduct.md
View File

@ -8,8 +8,8 @@ community_styles_migrated: true
<div class="community-section" id="cncf-code-of-conduct-intro">
<p>
쿠버네티스는
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF의 행동 강령</a>을 따르고 있습니다.
<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">커밋 214585e</a>
<a href="https://github.com/cncf/foundation/blob/main/code-of-conduct.md">CNCF의 행동 강령</a>을 따르고 있습니다.
<a href="https://github.com/cncf/foundation/blob/71b12a2f8b4589788ef2d69b351a3d035c68d927/code-of-conduct.md">커밋 71b12a2</a>
에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다.
만약 최신 버전이 아닌 경우에는
<a href="https://github.com/kubernetes/website/issues/new">이슈를 제기해 주세요</a>.

59
content/ko/community/static/cncf-code-of-conduct.md
View File

@ -1,28 +1,42 @@
<!-- Do not edit this file directly. Get the latest from
https://github.com/cncf/foundation/blob/master/code-of-conduct.md -->
## CNCF 커뮤니티 행동 강령 v1.0
https://github.com/cncf/foundation/blob/main/code-of-conduct.md -->
## CNCF 커뮤니티 행동 강령 v1.1
### 기여자 행동 강령
본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
CNCF 커뮤니티의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의
커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트,
풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는
모든 분들을 존중할 것을 약속합니다.
우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression),
성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교,
또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에
또는 국적에 상관 없이 모두가 차별 없는 환경에서 CNCF 커뮤니티에
참여할 수 있도록 최선을 다하고 있습니다.
## 범위
본 행동 강령은 프로젝트 활동 영역 내에서뿐만 아니라 개인이 프로젝트 또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
## CNCF 이벤트
CNCF 이벤트, 혹은 리눅스 재단에서 이벤트 전문 직원과 운영하는 이벤트는 이벤트 페이지에 명시된 Linux Foundation [이벤트 행동 강령](https://events.linuxfoundation.org/code-of-conduct)에 의거하여 운영됩니다. 해당 행동 강령은 CNCF의 행동 강령과 함께 사용하도록 고안되었습니다.
## 우리의 원칙
긍정적인 환경을 조성하는 행위는 다음과 같습니다.
* 타인에게 친절과 공감 실천
* 타인의 의견, 관점, 그리고 경험에 대한 포용
* 건설적 피드백에 대한 수용
* 실수에 대한 책임과 사과, 그리고 경험을 통한 배움
* 개인의 최선이 아닌 커뮤니티 전반의 선을 위한 노력
참여자에게 금지하는 행위의 예시는 다음과 같습니다.
- 성적인 언어 또는 이미지 사용
- 인신 공격
- 도발적이거나 모욕/경멸적인 코멘트
- 공개적이거나 사적인 괴롭힘
- 타인의 주소 및 전자주소와 같은 개인 정보의
동의 없는 공개
- 기타 비윤리적이거나 비전문적인 행동
* 성적인 언어 또는 이미지 사용, 혹은 그 외 성적으로 부적절한 행동
* 선동적, 모욕적, 경멸적 언사, 그리고 개인적 혹은 정치적 공격
* 공개적이거나 사적인 괴롭힘
* 타인의 주소 및 전자주소와 같은 개인 정보의 동의 없는 공개
* 기타 비윤리적이거나 비전문적인 행동
프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit),
코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정,
@ -31,15 +45,22 @@
행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서
영구적으로 제적될 수 있습니다.
본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트
또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다.
## 신고
쿠버네티스 커뮤니티에서 발생하는 사건들은 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 신고시 3일 내 회신을 받을 수 있습니다.
쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <mishi@linux.com>으로 문의해 주시기 바랍니다.
기타 다른 프로젝트에 관해서는 CNCF 직원에게 이메일 <conduct@cncf.io>으로 문의하십시오.
본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서
제공하는 버전 1.2.0을 적용하였으며, 해당 내용은
https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다.
CNCF는 외부 중재자로 Mishi Choudhary <mishi@linux.com>를 두고 있습니다. 외부 중재자는 CNCF 직원의 안내에 따라 의뢰 가능합니다. 보통의 경우 <conduct@cncf.io>로 직접 연락하는 것을 추천합니다.
### CNCF 이벤트 행동 강령
쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 <conduct@kubernetes.io>를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 <mishi@linux.com>으로 문의하십시오.
CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다.
## 집행
쿠버네티 프로젝트의 [행동 강령 위원회](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)가 행동 강령 발행을 시행합니다. 기타 프로젝트에 관하여는 CNCF가 행동강력 발행을 시행합니다.
양 기관은 처벌 없는 문제 해결을 추구합니다. 하지만 CNCF의 재량에 따라 회원 혹은 프로젝트를 퇴출시킬 수 있습니다.
### 확인
본 행동 강령은 기여자 서약(https://contributor-covenant.org)에서
제공하는 버전 2.0을 적용하였으며, 해당 내용은
https://contributor-covenant.org/version/2/0/code_of_conduct/ 에서 확인할 수 있습니다.

4
content/ko/docs/concepts/architecture/cloud-controller.md
View File

@ -8,8 +8,8 @@ weight: 40
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다.
쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를
클라우드 인프라스트럭처 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다.
쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭처를
신뢰한다.
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="클라우드 컨트롤러 매니저는">}}

10
content/ko/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -8,7 +8,7 @@ aliases:
<!-- overview -->
이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다.
@ -37,7 +37,7 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증
API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
* 파드에 대한 로그를 가져온다.
* 실행 중인 파드에 (kubectl을 통해) 연결한다.
* 실행 중인 파드에 (보통의 경우 kubectl을 통해) 연결한다.
* kubelet의 포트-포워딩 기능을 제공한다.
이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** .
@ -58,9 +58,11 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로
쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다.
이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다.
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
{{< note >}}
SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. [Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을 대체한다.
{{< note >}}
### Konnectivity 서비스
### Konnectivity 서비스 {#konnectivity-service}
{{< feature-state for_k8s_version="v1.18" state="beta" >}}

2
content/ko/docs/concepts/architecture/nodes.md
View File

@ -654,6 +654,6 @@ kubelet은 `LimitedSwap` 설정과 같은 행동을
* 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.
* [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다.
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node)
섹션을 읽어본다.
* [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.

2
content/ko/docs/concepts/cluster-administration/_index.md
View File

@ -63,7 +63,7 @@ no_list: true
### kubelet 보안
* [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
* [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)
* [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)
## 선택적 클러스터 서비스

10
content/ko/docs/concepts/cluster-administration/addons.md
View File

@ -18,19 +18,19 @@ content_type: concept
* [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다.
* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다.
* [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다.
* [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
* [CNI-Genie](https://github.com/cni-genie/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다.
* [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다.
* [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다.
* Multus는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다.
* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다.
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다.
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다.
* **Romana**는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다.
* [Romana](https://github.com/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다.
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다.
## 서비스 검색

2
content/ko/docs/concepts/cluster-administration/manage-deployment.md
View File

@ -454,7 +454,7 @@ deployment.apps/my-nginx scaled
kubectl edit deployment/my-nginx
```
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/concepts/workloads/controllers/deployment/)를 방문한다.
이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/tasks/debug/debug-application/debug-running-pod/)를 방문한다.

2
content/ko/docs/concepts/cluster-administration/networking.md
View File

@ -202,5 +202,5 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크
## {{% heading "whatsnext" %}}
네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
[네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에
[네트워킹 디자인 문서](https://git.k8s.io/design-proposals-archive/network/networking.md)에
자세히 설명되어 있다.

9
content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
View File

@ -18,7 +18,7 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스
{{< /note >}}
{{< warning >}}
신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다.
신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다.
신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다.
{{< /warning>}}
@ -150,16 +150,16 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치
## 프록시
다음과 같이 kubeconfig 파일에 `proxy-url`을 설정하여 `kubectl`이 프록시를 거치도록 설정할 수 있다.
다음과 같이 kubeconfig 파일에서 `proxy-url`를 사용하여 `kubectl`이 각 클러스터마다 프록시를 거치도록 설정할 수 있다.
```yaml
apiVersion: v1
kind: Config
proxy-url: https://proxy.host:3128
clusters:
- cluster:
proxy-url: http://proxy.example.org:3128
server: https://k8s.example.org/k8s/clusters/c-xxyyzz
name: development
users:
@ -168,7 +168,6 @@ users:
contexts:
- context:
name: development
```

39
content/ko/docs/concepts/configuration/secret.md
View File

@ -247,6 +247,8 @@ API 크리덴셜이 [TokenRequest](/docs/reference/kubernetes-api/authentication
예를 들어, 영원히 만료되지 않는 토큰이 필요한 경우에 활용할 수 있다.
그러나, 이렇게 하기보다는 API 접근에 필요한 토큰을 얻기 위해
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 서브리소스를 사용하는 것을 권장한다.
`TokenRequest` API로부터 토큰을 얻기 위해
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다.
{{< /note >}}
#### 특정 경로에 대한 시크릿 키 투영하기
@ -887,14 +889,29 @@ empty-secret Opaque 0 2m6s
`kubernetes.io/service-account-token` 시크릿 타입은
{{< glossary_tooltip text="서비스 어카운트" term_id="service-account" >}}를 확인하는
토큰을 저장하기 위해서 사용한다.
토큰 자격증명을 저장하기 위해서 사용한다.
1.22 버전 이후로는 이러한 타입의 시크릿은 더 이상 파드에 자격증명을 마운트하는 데 사용되지 않으며,
서비스 어카운트 토큰 시크릿 오브젝트를 사용하는 대신
[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 통해 토큰을 얻는 것이 추천된다.
`TokenRequest` API에서 얻은 토큰은 제한된 수명을 가지며 다른 API 클라이언트에서 읽을 수 없기 때문에
시크릿 오브젝트에 저장된 토큰보다 더 안전하다.
`TokenRequest` API에서 토큰을 얻기 위해서
[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다.
토큰을 얻기 위한 `TokenRequest` API를 사용할 수 없는 경우에는
서비스 어카운트 토큰 시크릿 오브젝트를 생성할 수 밖에 없으나,
이는 만료되지 않는 토큰 자격증명을 읽기 가능한 API 오브젝트로
지속되는 보안 노출 상황을 감수할 수 있는 경우에만 생성해야 한다.
이 시크릿 타입을 사용할 때는,
`kubernetes.io/service-account.name` 어노테이션이 존재하는
서비스 어카운트 이름으로 설정되도록 해야 한다.
쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
서비스 어카운트 이름으로 설정되도록 해야 한다. 만약 서비스 어카운트와
시크릿 오브젝트를 모두 생성하는 경우, 서비스 어카운트를 먼저 생성해야만 한다.
시크릿이 생성된 후, 쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
`kubernetes.io/service-account.uid` 어노테이션 및
`data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채우며,
이들은 인증 토큰을 보관한다.
인증 토큰을 보관하고 있는 `data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채운다.
다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다.
@ -911,17 +928,11 @@ data:
extra: YmFyCg==
```
`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을
생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스
어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다.
이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나
기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만
필요하다면, 이것이 권장되는 워크플로우이다.
시크릿을 만든 후, 쿠버네티스가 `data` 필드에 `token` 키를 채울 때까지 기다린다.
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면
서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다.
또한 파드에서 서비스 어카운트를 참조하는 방법을
또한 파드에서 서비스 어카운트 자격증명을 참조하는 방법에 대한 정보는
[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의
`automountServiceAccountToken` 필드와 `serviceAccountName`
필드를 통해 확인할 수 있다.
@ -982,7 +993,7 @@ kubectl create secret docker-registry secret-tiger-docker \
```
이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다.
다음 명령으로 이 새 시크릿에서 `.data.dockercfgjson` 필드를 덤프하고
다음 명령으로 이 새 시크릿에서 `.data.dockerconfigjson` 필드를 덤프하고
base64로 디코드하면,
```shell

79
content/ko/docs/concepts/configuration/windows-resource-management.md Normal file
View File

@ -0,0 +1,79 @@
---
# reviewers:
# - jayunit100
# - jsturtevant
# - marosset
# - perithompson
title: 윈도우 노드의 자원 관리
content_type: concept
weight: 75
---
<!-- overview -->
이 페이지는 리눅스와 윈도우 간에 리소스를 관리하는 방법의 차이점을 간략하게 설명한다.
<!-- body -->
리눅스 노드에서, {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}이
리소스 제어를 위한 파드 경계로서 사용된다.
컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다.
cpu/io/memory 통계를 수집하기 위해 cgroup API를 사용할 수 있다.
반대로, 윈도우는 시스템 네임스페이스 필터와 함께
컨테이너별로 [잡(job) 오브젝트](https://docs.microsoft.com/windows/win32/procthread/job-objects)를 사용하여
모든 프로세스를 컨테이너 안에 포함시키고 호스트와의 논리적 격리를 제공한다.
(잡 오브젝트는 윈도우의 프로세스 격리 메커니즘이며
쿠버네티스의 {{< glossary_tooltip term_id="job" text="잡(Job)" >}}과는 다른 것이다.)
네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다.
이는 곧 시스템 권한은 호스트 입장에서 주장할(assert) 수 없고,
이로 인해 특권을 가진(privileged) 컨테이너는 윈도우에서 사용할 수 없음을 의미한다.
또한 보안 계정 매니저(Security Account Manager, SAM)가 분리되어 있으므로
컨테이너는 호스트의 ID를 가정(assume)할 수 없다.
## 메모리 관리 {#resource-management-memory}
윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다.
윈도우는 모든 사용자 모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일(pagefile)이 필수이다.
윈도우 노드는 프로세스를 위해 메모리를 오버커밋(overcommit)하지 않는다.
이로 인해 윈도우는 메모리 컨디션에 도달하는 방식이 리눅스와 다르며,
프로세스는 메모리 부족(OOM, out of memory) 종료를 겪는 대신 디스크에 페이징을 수행한다.
메모리가 오버프로비저닝(over-provision)되고 전체 물리 메모리가 고갈되면,
페이징으로 인해 성능이 저하될 수 있다.
## CPU 관리 {#resource-management-cpu}
윈도우는 각 프로세스에 할당되는 CPU 시간의 양을 제한할 수는 있지만,
CPU 시간의 최소량을 보장하지는 않는다.
윈도우에서, kubelet은 kubelet 프로세스의
[스케줄링 우선 순위](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities)를 설정하기 위한 명령줄 플래그인
`--windows-priorityclass`를 지원한다.
이 플래그를 사용하면 윈도우 호스트에서 실행되는 kubelet 프로세스가 다른 프로세스보다 더 많은 CPU 시간 슬라이스를 할당받는다.
할당 가능한 값 및 각각의 의미에 대한 자세한 정보는
[윈도우 프라이어리티 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 확인할 수 있다.
실행 중인 파드가 kubelet의 CPU 사이클을 빼앗지 않도록 하려면, 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정한다.
## 리소스 예약 {#resource-reservation}
운영 체제, 컨테이너 런타임, 그리고 kubelet과 같은 쿠버네티스 호스트 프로세스가 사용하는 메모리 및 CPU를 고려하기 위해,
kubelet 플래그 `--kube-reserved` 및 `--system-reserved`를 사용하여
메모리 및 CPU 리소스의 예약이 가능하다 (그리고 필요하다).
윈도우에서 이들 값은 노드의
[할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스의 계산에만 사용된다.
{{< caution >}}
워크로드를 배포할 때, 컨테이너에 메모리 및 CPU 리소스 제한을 걸자.
이 또한 NodeAllocatable에서 차감되며, 클러스터 수준 스케줄러가 각 파드를 어떤 노드에 할당할지 결정하는 데 도움을 준다.
제한을 설정하지 않은 파드를 스케줄링하면 윈도우 노드가 오버프로비전될 수 있으며,
극단적인 경우 노드가 비정상 상태(unhealthy)로 될 수도 있다.
{{< /caution >}}
윈도우에서는, 메모리를 최소 2GB 이상 예약하는 것이 좋다.
얼마나 많은 양의 CPU를 예약할지 결정하기 위해,
각 노드의 최대 파드 수를 확인하고 해당 노드의 시스템 서비스의 CPU 사용량을 모니터링한 뒤,
워크로드 요구사항을 충족하는 값을 선택한다.

144
content/ko/docs/concepts/extend-kubernetes/_index.md
View File

@ -17,14 +17,14 @@ no_list: true
<!-- overview -->
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로
쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가
거의 없다.
쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 쿠버네티스 프로젝트를
포크하거나 코드에 패치를 제출할 필요가 거의 없다.
이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다.
쿠버네티스 클러스터를 업무 환경의 요구에 맞게
조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다.
잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는
쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도
어떤 익스텐션(extension) 포인트와 패턴이 있는지,
그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다.
@ -32,11 +32,14 @@ no_list: true
## 개요
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만
포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로
나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다.
## 구성
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다.
*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에
각 바이너리 별로 문서화되어 있다.
* [kubelet](/docs/reference/command-line-tools-reference/kubelet/)
* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)
@ -44,9 +47,22 @@ no_list: true
* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/)
* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/).
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서
플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경
가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후
쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시
시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다.
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/),
[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/),
[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및
역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은
*빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는
일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은
선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터
구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인
경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을
사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다.
## 익스텐션
@ -70,10 +86,9 @@ no_list: true
컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음
오브젝트의 `.status`를 업데이트 한다.
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고
원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를
*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을
추가한다.
컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때
이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 *웹훅 백엔드* 라고 한다. 컨트롤러와
마찬가지로 웹훅은 장애 지점을 추가한다.
웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
@ -95,15 +110,35 @@ kubectl에서 사용한다.
<!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다.
7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다.
[Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다.
개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나,
콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은
[API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는
쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를
추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로
*커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다.
커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
1. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지
방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다.
1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로
구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다.
1. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼
보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한
파드 네트워킹 구현이 가능하다.
1. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는
[스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다.
어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는
여러 유형의 익스텐션이 포함될 수 있다.
<!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
@ -112,60 +147,86 @@ kubectl에서 사용한다.
### 사용자 정의 유형
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고
`kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면
쿠버네티스에 커스텀 리소스를 추가하자.
애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다.
커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
커스텀 리소스에 대한 자세한 내용은
[커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다.
### 새로운 API와 자동화의 결합
사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
사용자 정의 리소스 API와 컨트롤 루프의 조합을
[오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은
특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한
사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다.
### 빌트인 리소스 변경
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다.
사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상
새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다.
API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API
접근 익스텐션은 영향을 준다.
### API 접근 익스텐션
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다.
요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후
다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에
대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를
참고하길 바란다.
이러한 각 단계는 익스텐션 포인트를 제공한다.
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에
있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여
확인할 수 있다(웹훅). 이러한 방법은 모두
[인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다.
### 인증
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다.
쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를
요청하는 클라이언트의 사용자 이름에 매핑한다.
쿠버네티스는 몇 가지 빌트인 인증 방법과
필요에 맞지 않는 경우
[인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다.
### 인가
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정
사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서
작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인
인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을
통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다.
### 동적 어드미션 컨트롤
요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다.
요청이 승인된 후, 쓰기 작업인 경우
[어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다.
빌트인 단계 외에도 몇 가지 익스텐션이 있다.
* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다.
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은
컨테이너에서 실행할 수 있는 이미지를 제한한다.
* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인
[어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을
사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다.
## 인프라스트럭처 익스텐션
### 스토리지 플러그인
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다.
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을
사용하면 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이
볼륨 유형을 마운트 할 수 있다.
FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때
추천하는 방식이다. 자세한 정보는
[스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서
찾을 수 있다.
### 장치 플러그인
@ -173,7 +234,6 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를
발견할 수 있게 해준다.
### 네트워크 플러그인
노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
@ -192,7 +252,7 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou
스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가
파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는
[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을
[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을
지원한다.
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -9,7 +9,7 @@ weight: 20
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는
[장치 플러그인 프레임워크](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)를
[장치 플러그인 프레임워크](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)를
제공한다.
공급 업체는 쿠버네티스 자체의 코드를 커스터마이징하는 대신, 수동 또는

41
content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md
View File

@ -14,6 +14,8 @@ weight: 10
쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다.
클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스).
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다.
[v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의
CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다.
쿠버네티스 플러그인은
@ -24,26 +26,37 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/
## 설치
CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. CRI는 자체 CNI 플러그인을 관리한다. 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다.
네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다.
* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다.
* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다.
{{< note >}}
쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다.
이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다.
dockershim 제거 후 문제가 발생하는 경우
[CNI 플러그인 관련 오류 문제 해결](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)을 참조하자.
{{< /note >}}
컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자.
- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni)
- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md)
CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 [네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조한다.
## 네트워크 플러그인 요구 사항
파드 네트워킹을 구성하고 정리하기 위해 [`NetworkPlugin` 인터페이스](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다.
iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다.
예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다.
플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다.
kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다.
### CNI
### 루프백 CNI
CNI 플러그인은 Kubelet에 `--network-plugin=cni` 커맨드라인 옵션을 전달하여 선택된다. Kubelet은 `--cni-conf-dir`(기본값은 `/etc/cni/net.d`)에서 파일을 읽고 해당 파일의 CNI 구성을 사용하여 각 파드의 네트워크를 설정한다. CNI 구성 파일은 [CNI 명세](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)와 일치해야 하며, 구성에서 참조하는 필수 CNI 플러그인은 `--cni-bin-dir`(기본값은 `/opt/cni/bin`)에 있어야 한다.
쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다.
루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91))
디렉터리에 여러 CNI 구성 파일이 있는 경우, kubelet은 이름별 알파벳 순으로 구성 파일을 사용한다.
구성 파일에 지정된 CNI 플러그인 외에도, 쿠버네티스는 최소 0.2.0 버전의 표준 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 플러그인이 필요하다.
#### hostPort 지원
### hostPort 지원
CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 [포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap)
플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다.
@ -80,7 +93,7 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인
}
```
#### 트래픽 셰이핑 지원
### 트래픽 셰이핑(shaping) 지원
**실험적인 기능입니다**
@ -132,8 +145,4 @@ metadata:
...
```
## 용법 요약
* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다.
## {{% heading "whatsnext" %}}

2
content/ko/docs/concepts/extend-kubernetes/operator.md
View File

@ -111,7 +111,9 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하
{{% thirdparty-content %}}
* [Charmed Operator Framework](https://juju.is/)
* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk)
* [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework)
* [kube-rs](https://kube.rs/) (Rust)
* [kubebuilder](https://book.kubebuilder.io/) 사용하기
* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK)
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)

232
content/ko/docs/concepts/extend-kubernetes/service-catalog.md
View File

@ -1,232 +0,0 @@
---
title: 서비스 카탈로그
content_type: concept
weight: 40
---
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다.
매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다.
{{< glossary_tooltip text="클러스터 오퍼레이터" term_id="cluster-operator" >}}는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다.
<!-- body -->
## 유스케이스 예제
한 {{< glossary_tooltip text="애플리케이션 개발자" term_id="application-developer" >}}가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다.
그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다.
다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다.
클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다.
따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다.
애플리케이션은 메시지 큐에 서비스로 접속할 수 있다.
## 아키텍처
서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다.
이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다.
<br>
![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg)
### API 리소스
서비스 카탈로그는 `servicecatalog.k8s.io` API를 설치하고 다음 쿠버네티스 리소스를 제공한다.
* `ClusterServiceBroker`: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표.
이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다.
* `ClusterServiceClass`: 특정 서비스 브로커가 제공하는 매니지드 서비스.
새로운 `ClusterServiceBroker` 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 `ClusterServiceClass` 리소스를 만든다.
* `ClusterServicePlan`: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. `ClusterServiceClass`와 유사하게, 새로운 `ClusterServiceBroker`가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 `ClusterServicePlan` 리소스를 작성한다.
* `ServiceInstance`: `ClusterServiceClass`의 프로비저닝된 인스턴스.
클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다.
새로운 `ServiceInstance`리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다.
* `ServiceBinding`: `ServiceInstance`에 대한 자격 증명에 액세스한다.
자신의 애플리케이션이 `ServiceInstance`를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다.
서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다.
### 인증
서비스 카탈로그는 다음의 인증 방법을 지원한다.
* 기본 (username/password)
* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
## 사용법
클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다.
1. 서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열.
1. 매니지드 서비스의 새 인스턴스 프로비저닝.
1. 연결 자격 증명을 반환하는 매니지드 서비스에 바인딩.
1. 연결 자격 증명을 애플리케이션에 매핑.
### 매니지드 서비스와 서비스 플랜 나열
먼저, 클러스터 운영자는 `servicecatalog.k8s.io` 그룹 내에 `ClusterServiceBroker` 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다.
다음은 `ClusterServiceBroker` 리소스 예시이다.
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceBroker
metadata:
name: cloud-broker
spec:
# 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.)
url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
#####
# bearer 토큰 정보 혹은 TLS용 caBundle과 같은
# 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다.
#####
```
다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다.
![List Services](/images/docs/service-catalog-list.svg)
1. `ClusterServiceBroker` 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다.
1. 서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 `ClusterServiceClass`와 `ClusterServicePlan` 리소스로 캐시된다.
1. 그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다.
kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
아래와 같은 형태의 서비스 이름 목록이 출력된다.
SERVICE NAME EXTERNAL NAME
4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
... ...
또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다.
kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
아래와 같은 형태의 플랜 이름 목록이 출력된다.
PLAN NAME EXTERNAL NAME
86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
... ...
### 새 인스턴스 프로비저닝
클러스터 운영자는 `ServiceInstance` 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다.
다음은 `ServiceInstance` 리소스의 예시이다.
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: cloud-queue-instance
namespace: cloud-apps
spec:
# 이전에 반환된 서비스 중 하나를 참조
clusterServiceClassExternalName: cloud-provider-service
clusterServicePlanExternalName: service-plan-name
#####
# 이곳에 서비스 브로커가 사용할 수 있는
# 파라미터를 추가할 수 있다.
#####
```
다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다.
![Provision a Service](/images/docs/service-catalog-provision.svg)
1. `ServiceInstance` 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다.
1. 서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다.
1. 그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다.
### 매니지드 서비스에 바인딩
새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 `ServiceBinding` 리소스를 생성하는 것으로 이루어진다.
다음은 `ServiceBinding` 리소스의 예시다.
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: cloud-queue-binding
namespace: cloud-apps
spec:
instanceRef:
name: cloud-queue-instance
#####
# 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의
# 추가 정보를 여기에 추가할 수 있다.
#####
```
다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다.
![Bind to a managed service](/images/docs/service-catalog-bind.svg)
1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다.
1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다.
1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다.
### 연결 자격 증명 매핑
바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다.
이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다.
<br>
![Map connection credentials](/images/docs/service-catalog-map.svg)
#### 파드 구성 파일
이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다.
다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `sa-key`라는 키는 `provider-cloud-key`라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 `/var/secrets/provider/key.json`에 마운트한다. 환경 변수 `PROVIDER_APPLICATION_CREDENTIALS`는 마운트된 파일의 값에서 매핑된다.
```yaml
...
spec:
volumes:
- name: provider-cloud-key
secret:
secretName: sa-key
containers:
...
volumeMounts:
- name: provider-cloud-key
mountPath: /var/secrets/provider
env:
- name: PROVIDER_APPLICATION_CREDENTIALS
value: "/var/secrets/provider/key.json"
```
다음 예시는 시크릿 값을 애플리케이션 환경 변수에 매핑하는 방법을 설명한다. 이 예시에서 메시지 큐 토픽 이름은 `topic` 라는 키의 `provider-queue-credentials` 시크릿에서 환경 변수 `TOPIC`에 매핑된다.
```yaml
...
env:
- name: "TOPIC"
valueFrom:
secretKeyRef:
name: provider-queue-credentials
key: topic
```
## {{% heading "whatsnext" %}}
* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다.
* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색

2
content/ko/docs/concepts/overview/kubernetes-api.md
View File

@ -76,7 +76,7 @@ card:
쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인
Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한
자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과
자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) 디자인 제안과
API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한
IDL(인터페이스 정의 언어) 파일을 참고한다.

2
content/ko/docs/concepts/overview/working-with-objects/names.md
View File

@ -100,4 +100,4 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
## {{% heading "whatsnext" %}}
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) 디자인 문서 읽기.

Some files were not shown because too many files have changed in this diff Show More