From 9581abbe2e3c5ff6755dd2f4cb4ce372c7d90f1f Mon Sep 17 00:00:00 2001 From: chrismetz09 Date: Mon, 7 Feb 2022 11:16:05 -0800 Subject: [PATCH 001/827] Add Figure to text and caption method described in [How to use captions](https://kubernetes.io/docs/contribute/style/diagram-guide/#how-to-use-captions) --- .../en/docs/contribute/new-content/open-a-pr.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 548dbac5d0..d50d9a1629 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -28,7 +28,7 @@ If your changes are large, read [Work from a local fork](#fork-the-repo) to lear ## Changes using GitHub If you're less experienced with git workflows, here's an easier method of -opening a pull request. The figure below outlines the steps and the details follow. +opening a pull request. Figure 1 outlines the steps and the details follow. @@ -61,7 +61,7 @@ class tasks,tasks2 white class id1 k8s {{}} -***Figure - Steps for opening a PR using GitHub*** +Figure 1. Steps for opening a PR using GitHub*** 1. On the page where you see the issue, select the pencil icon at the top right. You can also scroll to the bottom of the page and select **Edit this page**. @@ -122,7 +122,7 @@ work from a local fork. Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application. -The figure below shows the steps to follow when you work from a local fork. The details for each step follow. +Figure 2 shows the steps to follow when you work from a local fork. The details for each step follow. @@ -151,7 +151,8 @@ class 1,2,3,3a,4,5,6 grey class S,T spacewhite class changes,changes2 white {{}} -***Figure - Working from a local fork to make your changes*** + +Figure 2. Working from a local fork to make your changes*** ### Fork the kubernetes/website repository @@ -353,7 +354,7 @@ Alternately, install and use the `hugo` command on your computer: ### Open a pull request from your fork to kubernetes/website {#open-a-pr} -The figure below shows the steps to open a PR from your fork to the K8s/website. The details follow. +Figure 3 shows the steps to open a PR from your fork to the K8s/website. The details follow. @@ -379,7 +380,8 @@ classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:b class 1,2,3,4,5,6,7,8 grey class first,second white {{}} -***Figure - Steps to open a PR from your fork to the K8s/website*** + +Figure 3. Steps to open a PR from your fork to the K8s/website*** 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. 2. Select **New Pull Request**. From b66faef3f98e909e466722b60f31d9b85cf654ce Mon Sep 17 00:00:00 2001 From: chrismetz09 Date: Mon, 7 Feb 2022 13:15:19 -0800 Subject: [PATCH 002/827] removed *** at end of caption text --- content/en/docs/contribute/new-content/open-a-pr.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index d50d9a1629..5cec9164c4 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -61,7 +61,7 @@ class tasks,tasks2 white class id1 k8s {{}} -Figure 1. Steps for opening a PR using GitHub*** +Figure 1. Steps for opening a PR using GitHub 1. On the page where you see the issue, select the pencil icon at the top right. You can also scroll to the bottom of the page and select **Edit this page**. @@ -152,7 +152,7 @@ class S,T spacewhite class changes,changes2 white {{}} -Figure 2. Working from a local fork to make your changes*** +Figure 2. Working from a local fork to make your changes ### Fork the kubernetes/website repository @@ -381,7 +381,7 @@ class 1,2,3,4,5,6,7,8 grey class first,second white {{}} -Figure 3. Steps to open a PR from your fork to the K8s/website*** +Figure 3. Steps to open a PR from your fork to the K8s/website 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. 2. Select **New Pull Request**. From 37a47f2a94f99de261cb58718ce7a8956e63470c Mon Sep 17 00:00:00 2001 From: chrismetz09 Date: Mon, 7 Feb 2022 15:09:12 -0800 Subject: [PATCH 003/827] Add period after caption text --- content/en/docs/contribute/new-content/open-a-pr.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 5cec9164c4..b974e3a0f0 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -61,7 +61,7 @@ class tasks,tasks2 white class id1 k8s {{}} -Figure 1. Steps for opening a PR using GitHub +Figure 1. Steps for opening a PR using GitHub. 1. On the page where you see the issue, select the pencil icon at the top right. You can also scroll to the bottom of the page and select **Edit this page**. @@ -152,7 +152,7 @@ class S,T spacewhite class changes,changes2 white {{}} -Figure 2. Working from a local fork to make your changes +Figure 2. Working from a local fork to make your changes. ### Fork the kubernetes/website repository @@ -381,7 +381,7 @@ class 1,2,3,4,5,6,7,8 grey class first,second white {{}} -Figure 3. Steps to open a PR from your fork to the K8s/website +Figure 3. Steps to open a PR from your fork to the K8s/website. 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. 2. Select **New Pull Request**. From 7e546c83bee0ae0ef421a2262c2321f42b9cbe6a Mon Sep 17 00:00:00 2001 From: Vedant Koditkar Date: Tue, 15 Feb 2022 12:16:40 +0530 Subject: [PATCH 004/827] Update hyperlinks to point to main branch --- content/fr/docs/contribute/localization.md | 4 +--- content/fr/docs/contribute/participating.md | 10 ++++------ 2 files changed, 5 insertions(+), 9 deletions(-) diff --git a/content/fr/docs/contribute/localization.md b/content/fr/docs/contribute/localization.md index 91667afdd2..332aeb4ea4 100644 --- a/content/fr/docs/contribute/localization.md +++ b/content/fr/docs/contribute/localization.md @@ -147,7 +147,7 @@ La dernière version est **{{< latest-version >}}**, donc la branche de la relea ### Chaînes de sites en i18n/ -Les localisations doivent inclure le contenu des éléments suivants [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) dans un nouveau fichier spécifique à la langue. +Les localisations doivent inclure le contenu des éléments suivants [`i18n/en.toml`](https://github.com/kubernetes/website/blob/main/i18n/en.toml) dans un nouveau fichier spécifique à la langue. Prenons l'allemand comme exemple : `i18n/de.toml`. Ajouter un nouveau fichier de localisation dans `i18n/`. Par exemple, avec l'allemand (de) : @@ -230,5 +230,3 @@ Une fois qu'une traduction répond aux exigences de logistique et à une couvert - Activer la sélection de la langue sur le site Web - Publier la disponibilité de la traduction via les canaux de la [Cloud Native Computing Foundation](https://www.cncf.io/), y compris sur le blog de [Kubernetes](https://kubernetes.io/blog/). - - diff --git a/content/fr/docs/contribute/participating.md b/content/fr/docs/contribute/participating.md index 0658be231f..4fe2583859 100644 --- a/content/fr/docs/contribute/participating.md +++ b/content/fr/docs/contribute/participating.md @@ -102,7 +102,7 @@ Pour en savoir plus sur comment devenir un relecteur SIG Docs et sur les respons Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), vous pouvez devenir un relecteur SIG Docs. Les relecteurs d'autres SIG doivent demander séparément le statut de relecteur dans le SIG Docs. -Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépôt `kubernetes/website`. +Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dans le dépôt `kubernetes/website`. Affectez la PR à un ou plusieurs approbateurs SIG Docs. Si votre pull request est approuvée, vous êtes maintenant un relecteur SIG Docs. @@ -130,7 +130,7 @@ Pour en savoir plus sur comment devenir un approbateur SIG Docs et sur les respo Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), vous pouvez devenir un approbateur SIG Docs. Les approbateurs appartenant à d'autres SIG doivent demander séparément le statut d'approbateur dans SIG Docs. -Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépot `kubernetes/website`. +Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dans le dépot `kubernetes/website`. Affectez la PR à un ou plusieurs approbateurs SIG Docs. Si votre Pull Request est approuvée, vous êtes à présent approbateur SIG Docs. @@ -184,9 +184,9 @@ Le [dépôt du site web Kubernetes](https://github.com/kubernetes/website) utili - blunderbuss - approve -Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. +Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. -Un fichier [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. +Un fichier [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. Les fichiers OWNERS existent aussi dans les sous-dossiers, et peuvent ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants. Pour plus d'informations sur les fichiers OWNERS en général, voir [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). @@ -203,5 +203,3 @@ Pour plus d'informations sur la contribution à la documentation Kubernetes, voi - [Commencez à contribuer](/docs/contribute/start/) - [Documentation style](/docs/contribute/style/) - - From d05fb625f4e0f70279456eb2cbf50b73daf31f43 Mon Sep 17 00:00:00 2001 From: Martin Tovmassian Date: Tue, 8 Mar 2022 16:54:48 +0100 Subject: [PATCH 005/827] [en] Update Bash alias auto-completion --- content/en/docs/reference/kubectl/cheatsheet.md | 2 +- .../tasks/tools/included/optional-kubectl-configs-bash-linux.md | 2 +- .../tasks/tools/included/optional-kubectl-configs-bash-mac.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 8d995efb49..8be170b5f2 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -30,7 +30,7 @@ You can also use a shorthand alias for `kubectl` that also works with completion ```bash alias k=kubectl -complete -F __start_kubectl k +complete -o default -F __start_kubectl k ``` ### ZSH diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index 0024ff8bbc..8a5889b813 100644 --- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -43,7 +43,7 @@ If you have an alias for kubectl, you can extend shell completion to work with t ```bash echo 'alias k=kubectl' >>~/.bashrc -echo 'complete -F __start_kubectl k' >>~/.bashrc +echo 'complete -o default -F __start_kubectl k' >>~/.bashrc ``` {{< note >}} diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md index 9854540649..47243c575a 100644 --- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md +++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md @@ -77,7 +77,7 @@ You now have to ensure that the kubectl completion script gets sourced in all yo ```bash echo 'alias k=kubectl' >>~/.bash_profile - echo 'complete -F __start_kubectl k' >>~/.bash_profile + echo 'complete -o default -F __start_kubectl k' >>~/.bash_profile ``` - If you installed kubectl with Homebrew (as explained [here](/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)), then the kubectl completion script should already be in `/usr/local/etc/bash_completion.d/kubectl`. In that case, you don't need to do anything. From 5e9e7d0b21d15e4556ca1578e007f1a9c42820ca Mon Sep 17 00:00:00 2001 From: Stefan Midjich Date: Fri, 25 Mar 2022 10:23:26 +0100 Subject: [PATCH 006/827] Template syntax to retrieve values with dashes (-) in their key names This template syntax was not obvious to me until someone pointed it out on stackexchange, it should be in the cheatsheet for future users. Because trying to retrieve a value with dashes in its key-name using the normal template syntax will result in an error. --- content/en/docs/reference/kubectl/cheatsheet.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 3eaeb17ca9..95985c09af 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -177,6 +177,9 @@ kubectl get pods --selector=app=cassandra -o \ kubectl get configmap myconfig \ -o jsonpath='{.data.ca\.crt}' +# Retrieve a value with dashes instead of underscores. +kubectl get secret mysecret --template='{{index .data "key-name-with-dashes"}}' + # Get all worker nodes (use a selector to exclude results that have a label # named 'node-role.kubernetes.io/master') kubectl get node --selector='!node-role.kubernetes.io/master' From 81ffc6536d7093abd17c2b2368dc4b689533e390 Mon Sep 17 00:00:00 2001 From: Ali Mukadam Date: Fri, 1 Apr 2022 22:42:05 +1100 Subject: [PATCH 007/827] docs: added internal load balancer service annotations for Oracle Cloud Reviewed-by: Avi Miller Signed-off-by: Ali Mukadam --- .../en/docs/concepts/services-networking/service.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 85c222498e..e778f937c1 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -859,6 +859,17 @@ metadata: [...] ``` +{{% /tab %}} +{{% tab name="OCI" %}} + +```yaml +[...] +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/oci-load-balancer-internal: true +[...] +``` {{% /tab %}} {{< /tabs >}} From 223103bcf09dc9c7cfbb27addc91260803f235b7 Mon Sep 17 00:00:00 2001 From: carolina valencia Date: Thu, 2 Dec 2021 16:16:11 -0300 Subject: [PATCH 008/827] fix: broken link security pod policy --- content/pt-br/docs/concepts/security/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/pt-br/docs/concepts/security/overview.md b/content/pt-br/docs/concepts/security/overview.md index cfef9135f7..0cbbbf2961 100644 --- a/content/pt-br/docs/concepts/security/overview.md +++ b/content/pt-br/docs/concepts/security/overview.md @@ -103,7 +103,7 @@ vulnerável a um ataque de exaustão de recursos e, por consequência, o risco d Autorização RBAC (acesso à API Kubernetes) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Autenticação | https://kubernetes.io/docs/concepts/security/controlling-access/ Gerenciamento de segredos na aplicação (e encriptando-os no etcd em repouso) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ -Políticas de segurança do Pod | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ +Garantir que os Pods atendem aos padrões de segurança do Pod | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation Qualidade de serviço (e gerenciamento de recursos de cluster) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ Políticas de Rede | https://kubernetes.io/docs/concepts/services-networking/network-policies/ TLS para Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls From 6ce3dd22371ec661005acd09b215a1842c72d3c9 Mon Sep 17 00:00:00 2001 From: Mike Spreitzer Date: Mon, 11 Apr 2022 22:03:12 -0400 Subject: [PATCH 009/827] Update APF metrics again --- .../cluster-administration/flow-control.md | 57 +++++++++++++++++-- 1 file changed, 53 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 9e8f2a7923..68419b8231 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -471,11 +471,15 @@ poorly-behaved workloads that may be harming system health. requests, broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and `readOnly`). The observations are made - periodically at a high rate. + periodically at a high rate. Each observed value is a ratio, + between 0 and 1, of a number of requests divided by the + corresponding limit on the number of requests (queue length limit + for waiting and concurrency limit for executing). * `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a histogram vector of high or low water marks of the number of - requests broken down by the labels `phase` (which takes on the + requests (divided by the corresponding limit to get a ratio in the + range 0 to 1) broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and `readOnly`); the label `mark` takes on values `high` and `low`. The water marks are accumulated over @@ -502,11 +506,15 @@ poorly-behaved workloads that may be harming system health. values `waiting` and `executing`) and `priority_level`. Each histogram gets observations taken periodically, up through the last activity of the relevant sort. The observations are made at a high - rate. + rate. Each observed value is a ratio, between 0 and 1, of a number + of requests divided by the corresponding limit on the number of + requests (queue length limit for waiting and concurrency limit for + executing). * `apiserver_flowcontrol_priority_level_request_count_watermarks` is a histogram vector of high or low water marks of the number of - requests broken down by the labels `phase` (which takes on the + requests (divided by the corresponding limit to get a ratio in the + range 0 to 1) broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `priority_level`; the label `mark` takes on values `high` and `low`. The water marks are accumulated over windows bounded by the times when an observation @@ -514,6 +522,31 @@ poorly-behaved workloads that may be harming system health. `apiserver_flowcontrol_priority_level_request_count_samples`. These water marks show the range of values that occurred between samples. +* `apiserver_flowcontrol_priority_level_seat_count_samples` is a + histogram vector of observations of the utilization of a priority + level's concurrency limit, broken down by `priority_level`. This + utilization is the fraction (number of seats occupied) / + (concurrency limit). This metric considers all stages of execution + (both normal and the extra delay at the end of a write to cover for + the corresponding notification work) of all requests except WATCHes; + for those it considers only the initial stage that delivers + notifications of pre-existing objects. Each histogram in the vector + is also labeled with `phase: executing` (there is no seat limit for + the waiting phase). Each histogram gets observations taken + periodically, up through the last activity of the relevant sort. + The observations + are made at a high rate. + +* `apiserver_flowcontrol_priority_level_seat_count_watermarks` is a + histogram vector of high or low water marks of the utilization of a + priority level's concurrency limit, broken down by `priority_level` + and `mark` (which takes on values `high` and `low`). Each histogram + in the vector is also labeled with `phase: executing` (there is no + seat limit for the waiting phase). The water marks are accumulated + over windows bounded by the times when an observation was added to + `apiserver_flowcontrol_priority_level_seat_count_samples`. These + water marks show the range of values that occurred between samples. + * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a histogram vector of queue lengths for the queues, broken down by the labels `priority_level` and `flow_schema`, as sampled by the @@ -556,6 +589,22 @@ poorly-behaved workloads that may be harming system health. and `priority_level` (indicating the one to which the request was assigned). +* `apiserver_flowcontrol_watch_count_samples` is a histogram vector of + the number of active WATCH requests relevant to a given write, + broken down by `flow_schema` and `priority_level`. + +* `apiserver_flowcontrol_work_estimated_seats` is a histogram vector + of the number of estimated seats (maximum of initial and final stage + of execution) associated with requests, broken down by `flow_schema` + and `priority_level`. + +* `apiserver_flowcontrol_request_dispatch_no_accommodation_total` is a + counter vec of the number of events that in principle could have led + to a request being dispatched but did not, due to lack of available + concurrency, broken down by `flow_schema` and `priority_level`. The + relevant sorts of events are arrival of a request and completion of + a request. + ### Debug endpoints When you enable the API Priority and Fairness feature, the `kube-apiserver` From 6893daac2617b72f9c037e85b7b4d71f48878c70 Mon Sep 17 00:00:00 2001 From: Chris Burgess Date: Wed, 13 Apr 2022 21:05:08 +1200 Subject: [PATCH 010/827] Docs fix for kubectl proxy configuration Follow-up to https://github.com/kubernetes/website/pull/32245 --- .../configuration/organize-cluster-access-kubeconfig.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 713592cf98..b2b3870e86 100644 --- a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -150,16 +150,16 @@ are stored absolutely. ## Proxy -You can configure `kubectl` to use proxy by setting `proxy-url` in the kubeconfig file, like: +You can configure `kubectl` to use a proxy per cluster using `proxy-url` in your kubeconfig file, like this: ```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: @@ -167,8 +167,7 @@ users: contexts: - context: - name: development - + name: development ``` From 699c711de8b50de2dfd1493cfc9d35cfd86f1c74 Mon Sep 17 00:00:00 2001 From: Tim Allclair Date: Wed, 13 Apr 2022 16:53:37 -0700 Subject: [PATCH 011/827] [en] Clean up various broken links --- .../_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md | 2 +- ...6-09-00-High-Performance-Network-Policies-Kubernetes.md | 4 ++-- .../2017-08-00-High-Performance-Networking-With-Ec2.md | 7 ++----- 3 files changed, 5 insertions(+), 8 deletions(-) diff --git a/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md b/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md index 7289f57669..16fec78e4b 100644 --- a/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md +++ b/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md @@ -131,7 +131,7 @@ In this example, the ‘ **tenant-a** ’ namespace would get policy ‘ **pol1* -Today, [Romana](http://romana.io/), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) and [Calico](http://projectcalico.org/) support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).  +Today, [Romana](https://github.com/romana/romana), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) and [Calico](http://projectcalico.org/) support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).  diff --git a/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md b/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md index bc21d1edaa..59fdd5a708 100644 --- a/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md +++ b/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md @@ -65,7 +65,7 @@ Network policies are an exciting feature, which the Kubernetes community has wor -There are only a few policy-capable networking backends available for Kubernetes today: [Romana](http://romana.io/), [Calico](http://projectcalico.org/), and [Canal](https://github.com/tigera/canal); with [Weave](http://www.weave.works/) indicating support in the near future. Red Hat’s OpenShift includes network policy features as well. +There are only a few policy-capable networking backends available for Kubernetes today: [Romana](https://github.com/romana/romana), [Calico](http://projectcalico.org/), and [Canal](https://github.com/tigera/canal); with [Weave](http://www.weave.works/) indicating support in the near future. Red Hat’s OpenShift includes network policy features as well. @@ -189,4 +189,4 @@ These tests were performed using Romana as the backend policy provider and other -If you wish to try it for yourself, we invite you to check out [Romana](http://romana.io/). In our [GitHub repo](https://github.com/romana/romana) you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster. +If you wish to try it for yourself, we invite you to check out [Romana](https://github.com/romana/romana). In our [GitHub repo](https://github.com/romana/romana) you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster. diff --git a/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md b/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md index b735c501e7..44853d2567 100644 --- a/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md +++ b/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md @@ -9,7 +9,7 @@ url: /blog/2017/08/High-Performance-Networking-With-Ec2 One of the most popular platforms for running Kubernetes is Amazon Web Services’ Elastic Compute Cloud (AWS EC2). With more than a decade of experience delivering IaaS, and expanding over time to include a rich set of services with easy to consume APIs, EC2 has captured developer mindshare and loyalty worldwide. -When it comes to networking, however, EC2 has some limits that hinder performance and make deploying Kubernetes clusters to production unnecessarily complex. The preview release of [Romana v2.0](http://romana.io/), a network and security automation solution for Cloud Native applications, includes features that address some well known network issues when running Kubernetes in EC2. +When it comes to networking, however, EC2 has some limits that hinder performance and make deploying Kubernetes clusters to production unnecessarily complex. The preview release of [Romana v2.0](https://github.com/romana/romana), a network and security automation solution for Cloud Native applications, includes features that address some well known network issues when running Kubernetes in EC2. ## Traditional VPC Networking Performance Roadblocks @@ -40,7 +40,7 @@ Whether you were interested in advanced networking for traffic isolation or runn The way to avoid running out of VPC routes is to use them sparingly by making them forward pod traffic for multiple instances. From a networking perspective, what that means is that the VPC route needs to forward to a router, which can then forward traffic on to the final destination instance. -[Romana](http://romana.io/) is a CNI network provider that configures routes on the host to forward pod network traffic without an overlay. Since inter-node routes are installed on hosts, no VPC routes are necessary at all. However, when the VPC is split into subnets for an HA deployment across zones, VPC routes are necessary. +[Romana](https://github.com/romana/romana) is a CNI network provider that configures routes on the host to forward pod network traffic without an overlay. Since inter-node routes are installed on hosts, no VPC routes are necessary at all. However, when the VPC is split into subnets for an HA deployment across zones, VPC routes are necessary. Fortunately, inter-node routes on hosts allows them to act as a network router and forward traffic inbound from another zone just as it would for traffic from local pods. This makes any Kubernetes node configured by Romana able to accept inbound pod traffic from other zones and forward it to the proper destination node on the subnet. @@ -73,8 +73,5 @@ When using Romana v2.0, native VPC networking is now available for clusters of a ![](https://archive.org/download/hpc-ec2-vpc-2/hpc-ec2-vpc-2.png) -The preview release of Romana v2.0 is available [here](http://romana.io/preview). We welcome comments and feedback so we can make EC2 deployments of Kubernetes as fast and reliable as possible. - - -- _Juergen Brendel and Chris Marino, co-founders of Pani Networks, sponsor of the Romana project_ From c9ef193727559aef2a12f17d815af9dd47bc14cb Mon Sep 17 00:00:00 2001 From: Tim Allclair Date: Wed, 13 Apr 2022 17:06:54 -0700 Subject: [PATCH 012/827] [pt-br] Clean up various broken links --- content/pt-br/docs/concepts/cluster-administration/addons.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt-br/docs/concepts/cluster-administration/addons.md b/content/pt-br/docs/concepts/cluster-administration/addons.md index f3a00ae26d..0e0175cace 100644 --- a/content/pt-br/docs/concepts/cluster-administration/addons.md +++ b/content/pt-br/docs/concepts/cluster-administration/addons.md @@ -21,7 +21,7 @@ Esta página lista alguns dos complementos disponíveis e links com suas respect * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) une Flannel e Calico, fornecendo rede e política de rede. * [Cilium](https://github.com/cilium/cilium) é um plug-in de rede de camada 3 e de políticas de rede que pode aplicar políticas HTTP/API/camada 7 de forma transparente. Tanto o modo de roteamento quanto o de sobreposição/encapsulamento são suportados. Este plug-in também consegue operar no topo de outros plug-ins CNI. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) permite que o Kubernetes se conecte facilmente a uma variedade de plug-ins CNI, como Calico, Canal, Flannel, Romana ou Weave. -* [Contiv](http://contiv.github.io) oferece serviços de rede configuráveis para diferentes casos de uso (camada 3 nativa usando BGP, _overlay_ (sobreposição) usando vxlan, camada 2 clássica e Cisco-SDN/ACI) e também um _framework_ rico de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O [instalador](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. +* [Contiv](https://contivpp.io/) oferece serviços de rede configuráveis para diferentes casos de uso (camada 3 nativa usando BGP, _overlay_ (sobreposição) usando vxlan, camada 2 clássica e Cisco-SDN/ACI) e também um _framework_ rico de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O [instalador](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) é uma plataforma open source baseada no [Tungsten Fabric](https://tungsten.io) que oferece virtualização de rede multi-nuvem e gerenciamento de políticas de rede. O Contrail e o Tungsten Fabric são integrados a sistemas de orquestração de contêineres, como Kubernetes, OpenShift, OpenStack e Mesos, e fornecem modos de isolamento para cargas de trabalho executando em máquinas virtuais, contêineres/pods e servidores físicos. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) é um provedor de redes _overlay_ (sobrepostas) que pode ser usado com o Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) é um plug-in para suporte de múltiplas interfaces de rede em Pods do Kubernetes. @@ -30,7 +30,7 @@ Esta página lista alguns dos complementos disponíveis e links com suas respect * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) é uma plataforma de rede definida por software que fornece serviços de rede baseados em políticas entre os Pods do Kubernetes e os ambientes não-Kubernetes, com visibilidade e monitoramento de segurança. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) é um provedor de rede para o Kubernetes baseado no [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), uma implementação de redes virtuais que surgiu através do projeto Open vSwitch (OVS). O OVN-Kubernetes fornece uma implementação de rede baseada em _overlay_ (sobreposição) para o Kubernetes, incluindo uma implementação baseada em OVS para serviços de balanceamento de carga e políticas de rede. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) é um plug-in controlador CNI baseado no OVN (Open Virtual Network) que fornece serviços de rede _cloud native_, como _Service Function Chaining_ (SFC), redes _overlay_ (sobrepostas) OVN múltiplas, criação dinâmica de subredes, criação dinâmica de redes virtuais, provedor de rede VLAN e provedor de rede direto, e é plugável a outros plug-ins multi-rede. Ideal para cargas de trabalho que utilizam computação de borda _cloud native_ em redes multi-cluster. -* [Romana](http://romana.io) é uma solução de rede de camada 3 para redes de pods que também suporta a [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Detalhes da instalação do complemento Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize). +* [Romana](https://github.com/romana/romana) é uma solução de rede de camada 3 para redes de pods que também suporta a [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Detalhes da instalação do complemento Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornece rede e política de rede, funciona em ambos os lados de uma partição de rede e não requer um banco de dados externo. ## Descoberta de Serviço From 2d553512632884df94fbb00d744d4f1c7bbee0ec Mon Sep 17 00:00:00 2001 From: Abigail McCarthy Date: Thu, 14 Apr 2022 11:18:39 -0400 Subject: [PATCH 013/827] Update config.toml for language name standardization Update langiagenamelatinscript varibale Fix languageNameLatinScript update localization standards examples --- config.toml | 43 +++++++++++++++------- content/en/docs/contribute/localization.md | 7 ++-- 2 files changed, 33 insertions(+), 17 deletions(-) diff --git a/config.toml b/config.toml index c71f4fcdea..f2f90e2c05 100644 --- a/config.toml +++ b/config.toml @@ -303,7 +303,8 @@ languagedirection = "ltr" [languages.zh] title = "Kubernetes" description = "生产级别的容器编排系统" -languageName = "中文 Chinese" +languageName = "中文 (Chinese)" +languageNameLatinScript = "Chinese" weight = 2 contentDir = "content/zh" languagedirection = "ltr" @@ -315,7 +316,8 @@ language_alternatives = ["en"] [languages.ko] title = "Kubernetes" description = "운영 수준의 컨테이너 오케스트레이션" -languageName = "한국어 Korean" +languageName = "한국어 (Korean)" +languageNameLatinScript = "Korean" weight = 3 contentDir = "content/ko" languagedirection = "ltr" @@ -327,7 +329,8 @@ language_alternatives = ["en"] [languages.ja] title = "Kubernetes" description = "プロダクショングレードのコンテナ管理基盤" -languageName = "日本語 Japanese" +languageName = "日本語 (Japanese)" +languageNameLatinScript = "Japanese" weight = 4 contentDir = "content/ja" languagedirection = "ltr" @@ -339,7 +342,8 @@ language_alternatives = ["en"] [languages.fr] title = "Kubernetes" description = "Solution professionnelle d’orchestration de conteneurs" -languageName ="Français" +languageName ="Français (French)" +languageNameLatinScript = "Français" weight = 5 contentDir = "content/fr" languagedirection = "ltr" @@ -352,7 +356,8 @@ language_alternatives = ["en"] [languages.it] title = "Kubernetes" description = "Orchestrazione di Container in produzione" -languageName = "Italiano" +languageName = "Italiano (Italian)" +languageNameLatinScript = "Italiano" weight = 6 contentDir = "content/it" languagedirection = "ltr" @@ -365,7 +370,8 @@ language_alternatives = ["en"] [languages.no] title = "Kubernetes" description = "Production-Grade Container Orchestration" -languageName ="Norsk" +languageName ="Norsk (Norwegian)" +languageNameLatinScript = "Norsk" weight = 7 contentDir = "content/no" languagedirection = "ltr" @@ -378,7 +384,8 @@ language_alternatives = ["en"] [languages.de] title = "Kubernetes" description = "Produktionsreife Container-Orchestrierung" -languageName ="Deutsch" +languageName ="Deutsch (German)" +languageNameLatinScript = "Deutsch" weight = 8 contentDir = "content/de" languagedirection = "ltr" @@ -391,7 +398,8 @@ language_alternatives = ["en"] [languages.es] title = "Kubernetes" description = "Orquestación de contenedores para producción" -languageName ="Español" +languageName ="Español (Spanish)" +languageNameLatinScript = "Español" weight = 9 contentDir = "content/es" languagedirection = "ltr" @@ -404,7 +412,8 @@ language_alternatives = ["en"] [languages.pt-br] title = "Kubernetes" description = "Orquestração de contêineres em nível de produção" -languageName ="Português" +languageName ="Português (Portuguese)" +languageNameLatinScript = "Português" weight = 9 contentDir = "content/pt-br" languagedirection = "ltr" @@ -418,6 +427,7 @@ language_alternatives = ["en"] title = "Kubernetes" description = "Orkestrasi Kontainer dengan Skala Produksi" languageName ="Bahasa Indonesia" +languageNameLatinScript = "Bahasa Indonesia" weight = 10 contentDir = "content/id" languagedirection = "ltr" @@ -430,7 +440,8 @@ language_alternatives = ["en"] [languages.hi] title = "Kubernetes" description = "Production-Grade Container Orchestration" -languageName = "Hindi" +languageName = "हिन्दी (Hindi)" +languageNameLatinScript = "Hindi" weight = 11 contentDir = "content/hi" languagedirection = "ltr" @@ -442,7 +453,8 @@ language_alternatives = ["en"] [languages.vi] title = "Kubernetes" description = "Giải pháp điều phối container trong môi trường production" -languageName = "Tiếng Việt" +languageName = "Tiếng Việt (Vietnamese)" +languageNameLatinScript = "Tiếng Việt" contentDir = "content/vi" weight = 12 languagedirection = "ltr" @@ -450,7 +462,8 @@ languagedirection = "ltr" [languages.ru] title = "Kubernetes" description = "Первоклассная оркестрация контейнеров" -languageName = "Русский" +languageName = "Русский (Russian)" +languageNameLatinScript = "Russian" weight = 12 contentDir = "content/ru" languagedirection = "ltr" @@ -463,7 +476,8 @@ language_alternatives = ["en"] [languages.pl] title = "Kubernetes" description = "Produkcyjny system zarządzania kontenerami" -languageName = "Polski" +languageName = "Polski (Polish)" +languageNameLatinScript = "Polski" weight = 13 contentDir = "content/pl" languagedirection = "ltr" @@ -476,7 +490,8 @@ language_alternatives = ["en"] [languages.uk] title = "Kubernetes" description = "Довершена система оркестрації контейнерів" -languageName = "Українська" +languageName = "Українська (Ukrainian)" +languageNameLatinScript = "Ukrainian" weight = 14 contentDir = "content/uk" languagedirection = "ltr" diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 7630bdc7d9..97b15541f1 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -126,12 +126,14 @@ Add a configuration block for the new language to `config.toml`, under the exist title = "Kubernetes" description = "Produktionsreife Container-Verwaltung" languageName = "Deutsch (German)" -languageNameLatinScript = "German" +languageNameLatinScript = "Deutsch" contentDir = "content/de" weight = 8 ``` -The value for `languageName` will be listed in language selection bar. Assign "language name in native script (language name in latin script)" to `languageName`, for example, `languageName = "한국어 (Korean)"`. `languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`, for example, `languageNameLatinScript ="Korean"`. +The value for `languageName` will be listed in language selection bar. Assign "language name in native script and language (English language name in latin script)" to `languageName`. For example, `languageName = "한국어 (Korean)"` or `languageName = "Deutsch (German)"`. + +`languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`. For example, `languageNameLatinScript ="Korean"` or `languageNameLatinScript = "Deutsch"`. When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value. @@ -365,4 +367,3 @@ For more information about working from forks or directly from the repository, s ## Upstream contributions SIG Docs welcomes upstream contributions and corrections to the English source. - From 01efbac56fd917a80be576f4d74db23dd7c6d3ec Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Sun, 17 Apr 2022 08:32:38 +0700 Subject: [PATCH 014/827] fix: Well-Known Annotations/Labels/Taints examples --- .../labels-annotations-taints/_index.md | 82 +++++++++---------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index d08c6ca90c..9bb4ab12d8 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -17,7 +17,7 @@ This document serves both as a reference to the values and as a coordination poi ### app.kubernetes.io/component -Example: `app.kubernetes.io/component=database` +Example: `app.kubernetes.io/component: "database"` Used on: All Objects @@ -27,7 +27,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### app.kubernetes.io/created-by -Example: `app.kubernetes.io/created-by=controller-manager` +Example: `app.kubernetes.io/created-by: "controller-manager"` Used on: All Objects @@ -37,7 +37,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### app.kubernetes.io/instance -Example: `app.kubernetes.io/instance=mysql-abcxzy` +Example: `app.kubernetes.io/instance: "mysql-abcxzy"` Used on: All Objects @@ -47,7 +47,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### app.kubernetes.io/managed-by -Example: `app.kubernetes.io/managed-by=helm` +Example: `app.kubernetes.io/managed-by: "helm"` Used on: All Objects @@ -57,7 +57,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### app.kubernetes.io/name -Example: `app.kubernetes.io/name=mysql` +Example: `app.kubernetes.io/name: "mysql"` Used on: All Objects @@ -67,7 +67,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### app.kubernetes.io/part-of -Example: `app.kubernetes.io/part-of=wordpress` +Example: `app.kubernetes.io/part-of: "wordpress"` Used on: All Objects @@ -77,7 +77,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### app.kubernetes.io/version -Example: `app.kubernetes.io/version="5.7.21"` +Example: `app.kubernetes.io/version: "5.7.21"` Used on: All Objects @@ -87,7 +87,7 @@ One of the [recommended labels](/docs/concepts/overview/working-with-objects/com ### kubernetes.io/arch -Example: `kubernetes.io/arch=amd64` +Example: `kubernetes.io/arch: "amd64"` Used on: Node @@ -95,7 +95,7 @@ The Kubelet populates this with `runtime.GOARCH` as defined by Go. This can be h ### kubernetes.io/os -Example: `kubernetes.io/os=linux` +Example: `kubernetes.io/os: "linux"` Used on: Node @@ -103,7 +103,7 @@ The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be han ### kubernetes.io/metadata.name -Example: `kubernetes.io/metadata.name=mynamespace` +Example: `kubernetes.io/metadata.name: "mynamespace"` Used on: Namespaces @@ -124,7 +124,7 @@ This label has been deprecated. Please use `kubernetes.io/os` instead. ### kubernetes.io/hostname {#kubernetesiohostname} -Example: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal` +Example: `kubernetes.io/hostname: "ip-172-20-114-199.ec2.internal"` Used on: Node @@ -135,7 +135,7 @@ This label is also used as part of the topology hierarchy. See [topology.kubern ### kubernetes.io/change-cause {#change-cause} -Example: `kubernetes.io/change-cause=kubectl edit --record deployment foo` +Example: `kubernetes.io/change-cause: "kubectl edit --record deployment foo"` Used on: All Objects @@ -161,7 +161,7 @@ The value for this annotation must be **true** to take effect. This annotation i ### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} -Example: `controller.kubernetes.io/pod-deletion-cost=10` +Example: `controller.kubernetes.io/pod-deletion-cost: "10"` Used on: Pod @@ -174,7 +174,7 @@ which allows users to influence ReplicaSet downscaling order. The annotation par ### node.kubernetes.io/instance-type {#nodekubernetesioinstance-type} -Example: `node.kubernetes.io/instance-type=m3.medium` +Example: `node.kubernetes.io/instance-type: "m3.medium"` Used on: Node @@ -199,7 +199,7 @@ See [topology.kubernetes.io/zone](#topologykubernetesiozone). Example: -`statefulset.kubernetes.io/pod-name=mystatefulset-7` +`statefulset.kubernetes.io/pod-name: "mystatefulset-7"` When a StatefulSet controller creates a Pod for the StatefulSet, the control plane sets this label on that Pod. The value of the label is the name of the Pod being created. @@ -211,7 +211,7 @@ StatefulSet topic for more details. Example: -`topology.kubernetes.io/region=us-east-1` +`topology.kubernetes.io/region: "us-east-1"` See [topology.kubernetes.io/zone](#topologykubernetesiozone). @@ -219,7 +219,7 @@ See [topology.kubernetes.io/zone](#topologykubernetesiozone). Example: -`topology.kubernetes.io/zone=us-east-1c` +`topology.kubernetes.io/zone: "us-east-1c"` Used on: Node, PersistentVolume @@ -248,7 +248,7 @@ adding the labels manually (or adding support for `PersistentVolumeLabel`). With ### volume.beta.kubernetes.io/storage-provisioner (deprecated) -Example: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath` +Example: `volume.beta.kubernetes.io/storage-provisioner: "k8s.io/minikube-hostpath"` Used on: PersistentVolumeClaim @@ -272,7 +272,7 @@ This annotation will be added to dynamic provisioning required PVC. ### node.kubernetes.io/windows-build {#nodekubernetesiowindows-build} -Example: `node.kubernetes.io/windows-build=10.0.17763` +Example: `node.kubernetes.io/windows-build: "10.0.17763"` Used on: Node @@ -282,7 +282,7 @@ The label's value is in the format "MajorVersion.MinorVersion.BuildNumber". ### service.kubernetes.io/headless {#servicekubernetesioheadless} -Example: `service.kubernetes.io/headless=""` +Example: `service.kubernetes.io/headless: ""` Used on: Service @@ -290,7 +290,7 @@ The control plane adds this label to an Endpoints object when the owning Service ### kubernetes.io/service-name {#kubernetesioservice-name} -Example: `kubernetes.io/service-name="nginx"` +Example: `kubernetes.io/service-name: "nginx"` Used on: Service @@ -298,7 +298,7 @@ Kubernetes uses this label to differentiate multiple Services. Used currently fo ### endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} -Example: `endpointslice.kubernetes.io/managed-by="controller"` +Example: `endpointslice.kubernetes.io/managed-by: "controller"` Used on: EndpointSlices @@ -306,7 +306,7 @@ The label is used to indicate the controller or entity that manages an EndpointS ### endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror} -Example: `endpointslice.kubernetes.io/skip-mirror="true"` +Example: `endpointslice.kubernetes.io/skip-mirror: "true"` Used on: Endpoints @@ -314,7 +314,7 @@ The label can be set to `"true"` on an Endpoints resource to indicate that the E ### service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name} -Example: `service.kubernetes.io/service-proxy-name="foo-bar"` +Example: `service.kubernetes.io/service-proxy-name: "foo-bar"` Used on: Service @@ -326,7 +326,7 @@ Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"` Used on: Pod -The annotation is used to run Windows containers with Hyper-V isolation. To use Hyper-V isolation feature and create a Hyper-V isolated container, the kubelet should be started with feature gates HyperVContainer=true and the Pod should include the annotation experimental.windows.kubernetes.io/isolation-type=hyperv. +The annotation is used to run Windows containers with Hyper-V isolation. To use Hyper-V isolation feature and create a Hyper-V isolated container, the kubelet should be started with feature gates HyperVContainer=true and the Pod should include the annotation `experimental.windows.kubernetes.io/isolation-type: hyperv`. {{< note >}} You can only set this annotation on Pods that have a single container. @@ -349,7 +349,7 @@ Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassN ### storageclass.kubernetes.io/is-default-class -Example: `storageclass.kubernetes.io/is-default-class=true` +Example: `storageclass.kubernetes.io/is-default-class: true` Used on: StorageClass @@ -411,61 +411,61 @@ Use [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-tolera ### node.kubernetes.io/not-ready -Example: `node.kubernetes.io/not-ready:NoExecute` +Example: `node.kubernetes.io/not-ready: "NoExecute"` The node controller detects whether a node is ready by monitoring its health and adds or removes this taint accordingly. ### node.kubernetes.io/unreachable -Example: `node.kubernetes.io/unreachable:NoExecute` +Example: `node.kubernetes.io/unreachable: "NoExecute"` The node controller adds the taint to a node corresponding to the [NodeCondition](/docs/concepts/architecture/nodes/#condition) `Ready` being `Unknown`. ### node.kubernetes.io/unschedulable -Example: `node.kubernetes.io/unschedulable:NoSchedule` +Example: `node.kubernetes.io/unschedulable: "NoSchedule"` The taint will be added to a node when initializing the node to avoid race condition. ### node.kubernetes.io/memory-pressure -Example: `node.kubernetes.io/memory-pressure:NoSchedule` +Example: `node.kubernetes.io/memory-pressure: "NoSchedule"` The kubelet detects memory pressure based on `memory.available` and `allocatableMemory.available` observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed. ### node.kubernetes.io/disk-pressure -Example: `node.kubernetes.io/disk-pressure:NoSchedule` +Example: `node.kubernetes.io/disk-pressure :"NoSchedule"` The kubelet detects disk pressure based on `imagefs.available`, `imagefs.inodesFree`, `nodefs.available` and `nodefs.inodesFree`(Linux only) observed on a Node. The observed values are then compared to the corresponding thresholds that can be set on the kubelet to determine if the Node condition and taint should be added/removed. ### node.kubernetes.io/network-unavailable -Example: `node.kubernetes.io/network-unavailable:NoSchedule` +Example: `node.kubernetes.io/network-unavailable: "NoSchedule"` This is initially set by the kubelet when the cloud provider used indicates a requirement for additional network configuration. Only when the route on the cloud is configured properly will the taint be removed by the cloud provider. ### node.kubernetes.io/pid-pressure -Example: `node.kubernetes.io/pid-pressure:NoSchedule` +Example: `node.kubernetes.io/pid-pressure: "NoSchedule"` The kubelet checks D-value of the size of `/proc/sys/kernel/pid_max` and the PIDs consumed by Kubernetes on a node to get the number of available PIDs that referred to as the `pid.available` metric. The metric is then compared to the corresponding threshold that can be set on the kubelet to determine if the node condition and taint should be added/removed. ### node.cloudprovider.kubernetes.io/uninitialized -Example: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule` +Example: `node.cloudprovider.kubernetes.io/uninitialized: "NoSchedule"` Sets this taint on a node to mark it as unusable, when kubelet is started with the "external" cloud provider, until a controller from the cloud-controller-manager initializes this node, and then removes the taint. ### node.cloudprovider.kubernetes.io/shutdown -Example: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule` +Example: `node.cloudprovider.kubernetes.io/shutdown: "NoSchedule"` If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`. ### pod-security.kubernetes.io/enforce -Example: `pod-security.kubernetes.io/enforce: baseline` +Example: `pod-security.kubernetes.io/enforce: "baseline"` Used on: Namespace @@ -479,7 +479,7 @@ for more information. ### pod-security.kubernetes.io/enforce-version -Example: `pod-security.kubernetes.io/enforce-version: {{< skew latestVersion >}}` +Example: `pod-security.kubernetes.io/enforce-version: "{{< skew latestVersion >}}"` Used on: Namespace @@ -492,7 +492,7 @@ for more information. ### pod-security.kubernetes.io/audit -Example: `pod-security.kubernetes.io/audit: baseline` +Example: `pod-security.kubernetes.io/audit: "baseline"` Used on: Namespace @@ -506,7 +506,7 @@ for more information. ### pod-security.kubernetes.io/audit-version -Example: `pod-security.kubernetes.io/audit-version: {{< skew latestVersion >}}` +Example: `pod-security.kubernetes.io/audit-version: "{{< skew latestVersion >}}"` Used on: Namespace @@ -519,7 +519,7 @@ for more information. ### pod-security.kubernetes.io/warn -Example: `pod-security.kubernetes.io/warn: baseline` +Example: `pod-security.kubernetes.io/warn: "baseline"` Used on: Namespace @@ -535,7 +535,7 @@ for more information. ### pod-security.kubernetes.io/warn-version -Example: `pod-security.kubernetes.io/warn-version: {{< skew latestVersion >}}` +Example: `pod-security.kubernetes.io/warn-version: "{{< skew latestVersion >}}"` Used on: Namespace From bf0c2cfcf7f55b4571aef80fd6bd8d54330f8b1e Mon Sep 17 00:00:00 2001 From: Joel Gerber Date: Thu, 21 Apr 2022 11:35:46 -0400 Subject: [PATCH 015/827] Fix a minor typo in the 2nd paragraph of overview --- content/en/docs/reference/using-api/api-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 2e4fb85df2..a458cdff2d 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -15,7 +15,7 @@ primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET). For some resources, the API includes additional subresources that allow -fine grained authorization (such as a separating viewing details for a Pod from +fine grained authorization (such as separating viewing details for a Pod from retrieving its logs), and can accept and serve those resources in different representations for convenience or efficiency. From d9043dd29b5920fd4ec91a7c3a733fc538a3de48 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 21 Apr 2022 13:44:17 -0300 Subject: [PATCH 016/827] content/pt-br/docs/reference/glossary/cidr.md --- content/pt-br/docs/reference/glossary/cidr.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/cidr.md diff --git a/content/pt-br/docs/reference/glossary/cidr.md b/content/pt-br/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000..3073e6560c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cidr.md @@ -0,0 +1,17 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR é uma notação para descrever blocos de endereços IP e é muito usada em várias configurações de rede. + +aka: +tags: +- networking +--- +CIDR (em inglês - Classless Inter-Domain Routing) é uma notação para descrever blocos de endereços IP e é muito usada em várias configurações de rede. + + + +No contexto do Kubernetes, cada {{< glossary_tooltip text="Nó" term_id="node" >}} recebe um intervalo de endereços IP através do endereço inicial e uma máscara de sub-rede usando CIDR. Isso permite que os Nodes atribuam a cada {{< glossary_tooltip text="Pod" term_id="pod" >}} um endereço IP exclusivo. Embora originalmente seja um conceito para IPv4, o CIDR também foi expandido para incluir IPv6. \ No newline at end of file From 317f1e6eb90d7d5f04973cf847eabe90fc2e2e6f Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 21 Apr 2022 14:01:13 -0300 Subject: [PATCH 017/827] Add content/pt-br/docs/reference/glossary/volume-plugin.md --- .../docs/reference/glossary/volume-plugin.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/volume-plugin.md diff --git a/content/pt-br/docs/reference/glossary/volume-plugin.md b/content/pt-br/docs/reference/glossary/volume-plugin.md new file mode 100644 index 0000000000..1936fdf3f2 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/volume-plugin.md @@ -0,0 +1,18 @@ +--- +title: Plugin de Volume +id: volumeplugin +date: 2018-04-12 +full_link: +short_description: > + Um plugin de volume permite a integração do armazenamento dentro de um Pod. + +aka: +tags: +- core-object +- storage +--- + Um plugin de volume permite a integração do armazenamento dentro de um {{< glossary_tooltip text="Pod" term_id="pod" >}}. + + + +Um plugin de volume permite anexar e montar volumes de armazenamento para uso por um {{< glossary_tooltip text="Pod" term_id="pod" >}}. Os plugins de volume podem estar _dentro_ ou _fora da árvore_. _Na árvore_, os plugins fazem parte do repositório de código Kubernetes e seguem seu ciclo de lançamento. Os plugins _fora da árvore_ são desenvolvidos de forma independente. \ No newline at end of file From cc961533dedd08fd6b7ed5f9e1b30124f39210fe Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 21 Apr 2022 14:29:33 -0300 Subject: [PATCH 018/827] Add content/pt-br/docs/reference/glossary/sysctl.md --- .../pt-br/docs/reference/glossary/sysctl.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/sysctl.md diff --git a/content/pt-br/docs/reference/glossary/sysctl.md b/content/pt-br/docs/reference/glossary/sysctl.md new file mode 100644 index 0000000000..060c2e2698 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/sysctl.md @@ -0,0 +1,19 @@ +--- +title: sysctl +id: sysctl +date: 2019-02-12 +full_link: /docs/tasks/administer-cluster/sysctl-cluster/ +short_description: > + Uma interface para obter e definir parâmetros do kernel Unix. + +aka: +tags: +- tool +--- + `sysctl` é uma interface semi-padronizada para ler ou alterar os atributos do kernel Unix em execução. + + + +Em sistemas do tipo Unix-like, `sysctl` é tanto o nome da ferramenta que os administradores usam para visualizar e modificar essas configurações, quanto a chamada do sistema que a ferramenta usa. + +Os {{< glossary_tooltip text="Contêiner" term_id="container" >}} em execução e os plugins de rede podem depender dos valores definidos do `sysctl`. \ No newline at end of file From d353f8ceb332dbc7f10182a77bed7fa5261c0e23 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 21 Apr 2022 14:39:00 -0300 Subject: [PATCH 019/827] Add content/pt-br/docs/reference/glossary/sig.md --- content/pt-br/docs/reference/glossary/sig.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/sig.md diff --git a/content/pt-br/docs/reference/glossary/sig.md b/content/pt-br/docs/reference/glossary/sig.md new file mode 100644 index 0000000000..8d87706100 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/sig.md @@ -0,0 +1,19 @@ +--- +title: SIG (grupo de interesse especial) +id: sig +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list +short_description: > + Membros da comunidade que gerenciam coletivamente uma parte ou continuamente um projeto maior de código aberto do Kubernetes. + +aka: +tags: +- community +--- + {{< glossary_tooltip text="Membros da comunidade" term_id="member" >}} que gerenciam coletivamente uma parte ou continuamente um projeto maior de código aberto do Kubernetes. + + + +Os membros dentro de um grupo de interesse especial (do inglês - Special Interest Group, SIG) têm um interesse comum em avançar em uma área específica, como arquitetura, API ou documentação. Os SIGs devem seguir as [diretrizes de governança](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) do SIG, mas podem ter sua própria política de contribuição e canais de comunicação. + +Para mais informações, consulte o repositório [kubernetes/community](https://github.com/kubernetes/community) e a lista atual de [SIGs e Grupos de Trabalho](https://github.com/kubernetes/community/blob/master/sig-list.md). From 69a3fc37750e7d72712fcbd09a42dcbb694cc62f Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 21 Apr 2022 14:47:45 -0300 Subject: [PATCH 020/827] Add content/pt-br/docs/reference/glossary/reviewer.md --- .../pt-br/docs/reference/glossary/reviewer.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/reviewer.md diff --git a/content/pt-br/docs/reference/glossary/reviewer.md b/content/pt-br/docs/reference/glossary/reviewer.md new file mode 100644 index 0000000000..ff367087ee --- /dev/null +++ b/content/pt-br/docs/reference/glossary/reviewer.md @@ -0,0 +1,17 @@ +--- +title: Revisor +id: reviewer +date: 2018-04-12 +full_link: +short_description: > + Uma pessoa que revisa o código quanto à qualidade e correção em alguma parte do projeto. + +aka: +tags: +- community +--- + Uma pessoa que revisa o código quanto à qualidade e correção em alguma parte do projeto. + + + +Os revisores têm conhecimento sobre o código base e os princípios de engenharia de software. O estado do revisor é atribuído a uma parte do código. \ No newline at end of file From b4214f357222bd8d85e5843c94d2ea2ba1803372 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 21 Apr 2022 15:06:20 -0300 Subject: [PATCH 021/827] Add content/pt-br/docs/reference/glossary/rbac.md --- content/pt-br/docs/reference/glossary/rbac.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/rbac.md diff --git a/content/pt-br/docs/reference/glossary/rbac.md b/content/pt-br/docs/reference/glossary/rbac.md new file mode 100644 index 0000000000..283653ed97 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/rbac.md @@ -0,0 +1,18 @@ +--- +title: RBAC (Controle de Acesso Baseado em Funções) +id: rbac +date: 2018-04-12 +full_link: /docs/reference/access-authn-authz/rbac/ +short_description: > + Gerencia decisões de autorização, permitindo que os administradores configurem dinamicamente políticas de acesso por meio da API do Kubernetes. + +aka: +tags: +- security +- fundamental +--- + Gerencia decisões de autorização, permitindo que os administradores configurem dinamicamente políticas de acesso por meio da {{< glossary_tooltip text="API do Kubernetes" term_id="kubernetes-api" >}}. + + + +O RBAC (do inglês - Role-Based Access Control) utiliza *funções*, que contêm regras de permissão, e *atribuição das funções*, que concedem as permissões definidas em uma função a um conjunto de usuários. \ No newline at end of file From d0174ae576314b1441abfa66067902f93f0feba1 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" <98214640+MrErlison@users.noreply.github.com> Date: Thu, 21 Apr 2022 19:27:09 -0300 Subject: [PATCH 022/827] Update content/pt-br/docs/reference/glossary/rbac.md Co-authored-by: Tim Bannister --- content/pt-br/docs/reference/glossary/rbac.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/pt-br/docs/reference/glossary/rbac.md b/content/pt-br/docs/reference/glossary/rbac.md index 283653ed97..b868363fde 100644 --- a/content/pt-br/docs/reference/glossary/rbac.md +++ b/content/pt-br/docs/reference/glossary/rbac.md @@ -6,7 +6,9 @@ full_link: /docs/reference/access-authn-authz/rbac/ short_description: > Gerencia decisões de autorização, permitindo que os administradores configurem dinamicamente políticas de acesso por meio da API do Kubernetes. -aka: +aka: + - Role Based Access Control + - Controle de Acesso Baseado em Funções tags: - security - fundamental From 400e10a832ba1cba70b81fafde1f432c44c4d3a9 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 21 Apr 2022 10:53:28 +0900 Subject: [PATCH 023/827] Update Hugo version --- Dockerfile | 4 ++-- netlify.toml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Dockerfile b/Dockerfile index a45fa4f0ac..fecd5b0503 100644 --- a/Dockerfile +++ b/Dockerfile @@ -4,7 +4,7 @@ # change is that the Hugo version is now an overridable argument rather than a fixed # environment variable. -FROM golang:1.16-alpine +FROM golang:1.18-alpine LABEL maintainer="Luc Perkins " @@ -24,7 +24,7 @@ RUN mkdir $HOME/src && \ cd "hugo-${HUGO_VERSION}" && \ go install --tags extended -FROM golang:1.16-alpine +FROM golang:1.18-alpine RUN apk add --no-cache \ runuser \ diff --git a/netlify.toml b/netlify.toml index 0aee361f39..dc4b3e7042 100644 --- a/netlify.toml +++ b/netlify.toml @@ -8,7 +8,7 @@ command = "git submodule update --init --recursive --depth 1 && make non-product [build.environment] NODE_VERSION = "10.20.0" -HUGO_VERSION = "0.87.0" +HUGO_VERSION = "0.97.0" RUBY_VERSION = "3.0.1" [context.production.environment] From 1dcbae36ea3a0e7a856144bf4da7434088801356 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Fri, 22 Apr 2022 07:52:36 -0300 Subject: [PATCH 024/827] Add content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md --- .../setup-tools/kubeadm/kubeadm-version.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md diff --git a/content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md b/content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md new file mode 100644 index 0000000000..5bf2ed0e31 --- /dev/null +++ b/content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-version.md @@ -0,0 +1,13 @@ +--- +reviewers: +- luxas +- jbeda +title: kubeadm version +content_type: conceito +weight: 80 +--- + +Este comando exibe a versão do kubeadm. + + +{{< include "generated/kubeadm_version.md" >}} From f3adb2cd66aea0aed3d5d78f90da46409bac0ffb Mon Sep 17 00:00:00 2001 From: Joel Gerber Date: Fri, 22 Apr 2022 07:06:31 -0400 Subject: [PATCH 025/827] Update content/en/docs/reference/using-api/api-concepts.md Co-authored-by: divya-mohan0209 --- content/en/docs/reference/using-api/api-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index a458cdff2d..a7a8f1d059 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -15,7 +15,7 @@ primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET). For some resources, the API includes additional subresources that allow -fine grained authorization (such as separating viewing details for a Pod from +fine grained authorization (such as separate viewing details for a Pod from retrieving its logs), and can accept and serve those resources in different representations for convenience or efficiency. From a54d1d047719e85d127e2463f655ff028b26ff5c Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Fri, 22 Apr 2022 08:44:07 -0300 Subject: [PATCH 026/827] Add pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md --- .../setup-tools/kubeadm/kubeadm-token.md | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md diff --git a/content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md b/content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md new file mode 100644 index 0000000000..406d3b2983 --- /dev/null +++ b/content/pt-br/docs/reference/setup-tools/kubeadm/kubeadm-token.md @@ -0,0 +1,27 @@ +--- +title: kubeadm token +content_type: conceito +weight: 70 +--- + + +Os Bootstrap tokens são usados para estabelecer uma relação de confiança bidirecional entre um nó que se junta ao cluster e um nó do plano de controle, conforme descrito na [autenticação com tokens de inicialização](/docs/reference/access-authn-authz/bootstrap-tokens/). + +O `kubeadm init` cria um token inicial com um TTL de 24 horas. Os comandos a seguir permitem que você gerencie esse token e também crie e gerencie os novos. + + +## Criar um token kubeadm {#cmd-token-create} +{{< include "generated/kubeadm_token_create.md" >}} + +## Excluir um token kubeadm {#cmd-token-delete} +{{< include "generated/kubeadm_token_delete.md" >}} + +## Gerar um token kubeadm {#cmd-token-generate} +{{< include "generated/kubeadm_token_generate.md" >}} + +## Listar um token kubeadm {#cmd-token-list} +{{< include "generated/kubeadm_token_list.md" >}} + +## {{% heading "O que vem a seguir?" %}} + +* [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join) para inicializar um nó `worker` do Kubernetes e associá-lo ao cluster \ No newline at end of file From ca7ff4b5c9de61a6c10a8dfadf80c09ac88733a2 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Fri, 22 Apr 2022 09:19:49 -0300 Subject: [PATCH 027/827] Add folder setup-tools/kubeadm/generated/ --- .../docs/reference/setup-tools/kubeadm/generated/README.md | 1 + .../docs/reference/setup-tools/kubeadm/generated/_index.md | 6 ++++++ 2 files changed, 7 insertions(+) create mode 100644 content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md create mode 100644 content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md diff --git a/content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md b/content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md new file mode 100644 index 0000000000..020bc76f62 --- /dev/null +++ b/content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md @@ -0,0 +1 @@ +All files in this directory are auto-generated from other repos. **Do not edit them manually. You must edit them in their upstream repo.** \ No newline at end of file diff --git a/content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md b/content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md new file mode 100644 index 0000000000..7ebf753ae9 --- /dev/null +++ b/content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md @@ -0,0 +1,6 @@ +--- +title: "Kubeadm Generated" +weight: 10 +toc_hide: true +--- + From 08a1fa5f13b29ed36d5f807f74cf758d4d8c7f5f Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Sat, 23 Apr 2022 08:08:00 -0300 Subject: [PATCH 028/827] Remove folder generated --- .../docs/reference/setup-tools/kubeadm/generated/README.md | 1 - .../docs/reference/setup-tools/kubeadm/generated/_index.md | 6 ------ 2 files changed, 7 deletions(-) delete mode 100644 content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md delete mode 100644 content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md diff --git a/content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md b/content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md deleted file mode 100644 index 020bc76f62..0000000000 --- a/content/pt-br/docs/reference/setup-tools/kubeadm/generated/README.md +++ /dev/null @@ -1 +0,0 @@ -All files in this directory are auto-generated from other repos. **Do not edit them manually. You must edit them in their upstream repo.** \ No newline at end of file diff --git a/content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md b/content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md deleted file mode 100644 index 7ebf753ae9..0000000000 --- a/content/pt-br/docs/reference/setup-tools/kubeadm/generated/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Kubeadm Generated" -weight: 10 -toc_hide: true ---- - From aec5647e90c712b474b8f3a89a1775b33203e43d Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Sat, 23 Apr 2022 12:28:05 -0300 Subject: [PATCH 029/827] Add pt-br/docs/reference/glossary/cluster-infrastructure.md --- .../reference/glossary/cluster-infrastructure.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/cluster-infrastructure.md diff --git a/content/pt-br/docs/reference/glossary/cluster-infrastructure.md b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md new file mode 100644 index 0000000000..44a6e9f156 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md @@ -0,0 +1,13 @@ +--- +title: infraestrutura de Cluster +id: cluster-infrastructure +date: 2019-05-12 +full_link: +short_description: > + A camada de infraestrutura fornece e mantém máquinas virtuais, redes, grupos de segurança e outros. + +aka: +tags: +- operation +--- + A camada de infraestrutura fornece e mantém máquinas virtuais, redes, grupos de segurança e outros. From c3566e471d149118a94a29fbf422a358c0b64025 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Sat, 23 Apr 2022 12:34:14 -0300 Subject: [PATCH 030/827] Add pt-br/docs/reference/glossary/application-developer.md --- .../reference/glossary/application-developer.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/application-developer.md diff --git a/content/pt-br/docs/reference/glossary/application-developer.md b/content/pt-br/docs/reference/glossary/application-developer.md new file mode 100644 index 0000000000..037a9413ad --- /dev/null +++ b/content/pt-br/docs/reference/glossary/application-developer.md @@ -0,0 +1,17 @@ +--- +title: Desenvolvedor de Aplicativos +id: application-developer +date: 2018-04-12 +full_link: +short_description: > + Uma pessoa que escreve um aplicativo que é executado em um cluster Kubernetes. + +aka: +tags: +- user-type +--- + Uma pessoa que escreve um aplicativo que é executado em um cluster Kubernetes. + + + +Um desenvolvedor de aplicativos se concentra em uma parte da aplicação. O seu foco pode variar significativamente em tamanho. From 2725b2aef83acce01e2bece36ff71900ab83971e Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Sat, 23 Apr 2022 12:54:42 -0300 Subject: [PATCH 031/827] pt-br/docs/reference/glossary/ingress.md --- .../pt-br/docs/reference/glossary/ingress.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/ingress.md diff --git a/content/pt-br/docs/reference/glossary/ingress.md b/content/pt-br/docs/reference/glossary/ingress.md new file mode 100644 index 0000000000..202752a919 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/ingress.md @@ -0,0 +1,20 @@ +--- +title: Ingress +id: ingress +date: 2018-04-12 +full_link: /docs/concepts/services-networking/ingress/ +short_description: > + Um objeto API que gerencia o acesso externo aos serviços em um cluster, normalmente HTTP. + +aka: +tags: +- networking +- architecture +- extension +--- + Um objeto API que gerencia o acesso externo aos serviços em um cluster, normalmente HTTP. + + + +Ingress may provide load balancing, SSL termination and name-based virtual hosting. +O Ingress pode fornecer um balanceamento de carga, descriptografia SSL e hospedagem virtual baseada em nome. From 258499fedd11ffb6742872e8a411e3b58e52c4dc Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Sat, 23 Apr 2022 12:58:10 -0300 Subject: [PATCH 032/827] Update term API and remove english sentence --- content/pt-br/docs/reference/glossary/ingress.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/pt-br/docs/reference/glossary/ingress.md b/content/pt-br/docs/reference/glossary/ingress.md index 202752a919..5f999e9541 100644 --- a/content/pt-br/docs/reference/glossary/ingress.md +++ b/content/pt-br/docs/reference/glossary/ingress.md @@ -12,9 +12,8 @@ tags: - architecture - extension --- - Um objeto API que gerencia o acesso externo aos serviços em um cluster, normalmente HTTP. + Um objeto API (do inglês "Application Programming Interface") que gerencia o acesso externo aos serviços em um cluster, normalmente HTTP. -Ingress may provide load balancing, SSL termination and name-based virtual hosting. O Ingress pode fornecer um balanceamento de carga, descriptografia SSL e hospedagem virtual baseada em nome. From c00146a3a67c216524998a7fa3c2761eba28ab86 Mon Sep 17 00:00:00 2001 From: Joel Gerber Date: Mon, 25 Apr 2022 07:41:33 -0400 Subject: [PATCH 033/827] Update content/en/docs/reference/using-api/api-concepts.md Co-authored-by: divya-mohan0209 --- content/en/docs/reference/using-api/api-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index a7a8f1d059..f31bfaff40 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -15,7 +15,7 @@ primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET). For some resources, the API includes additional subresources that allow -fine grained authorization (such as separate viewing details for a Pod from +fine grained authorization (such as separate views for Pod details and retrieving its logs), and can accept and serve those resources in different representations for convenience or efficiency. From 47be146d8625f1d8590ac0a1af4d8aef82644179 Mon Sep 17 00:00:00 2001 From: Joel Gerber Date: Mon, 25 Apr 2022 07:41:46 -0400 Subject: [PATCH 034/827] Update content/en/docs/reference/using-api/api-concepts.md Co-authored-by: divya-mohan0209 --- content/en/docs/reference/using-api/api-concepts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index f31bfaff40..1a722acffd 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -16,7 +16,7 @@ GET). For some resources, the API includes additional subresources that allow fine grained authorization (such as separate views for Pod details and -retrieving its logs), and can accept and serve those resources in different +log retrievals), and can accept and serve those resources in different representations for convenience or efficiency. Kubernetes supports efficient change notifications on resources via *watches*. From ce4573404566cff0f28dbe6106afe82faa8c8a1e Mon Sep 17 00:00:00 2001 From: Tim Allclair Date: Tue, 26 Apr 2022 11:47:23 -0700 Subject: [PATCH 035/827] Remove romana links from blog posts --- .../_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md | 2 +- ...16-09-00-High-Performance-Network-Policies-Kubernetes.md | 6 +++--- .../2017-08-00-High-Performance-Networking-With-Ec2.md | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md b/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md index 16fec78e4b..b2a5561dd9 100644 --- a/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md +++ b/content/en/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md @@ -131,7 +131,7 @@ In this example, the ‘ **tenant-a** ’ namespace would get policy ‘ **pol1* -Today, [Romana](https://github.com/romana/romana), [OpenShift](https://www.openshift.com/), [OpenContrail](http://www.opencontrail.org/) and [Calico](http://projectcalico.org/) support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).  +Today, Romana, OpenShift, OpenContrail and Calico support network policies applied to namespaces and pods. Cisco and VMware are working on implementations as well. Both Romana and Calico demonstrated these capabilities with Kubernetes 1.2 recently at KubeCon. You can watch their presentations here: [Romana](https://www.youtube.com/watch?v=f-dLKtK6qCs) ([slides](http://www.slideshare.net/RomanaProject/kubecon-london-2016-ronana-cloud-native-sdn)), [Calico](https://www.youtube.com/watch?v=p1zfh4N4SX0) ([slides](http://www.slideshare.net/kubecon/kubecon-eu-2016-secure-cloudnative-networking-with-project-calico)).  diff --git a/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md b/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md index 59fdd5a708..c8c452bc67 100644 --- a/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md +++ b/content/en/blog/_posts/2016-09-00-High-Performance-Network-Policies-Kubernetes.md @@ -65,7 +65,7 @@ Network policies are an exciting feature, which the Kubernetes community has wor -There are only a few policy-capable networking backends available for Kubernetes today: [Romana](https://github.com/romana/romana), [Calico](http://projectcalico.org/), and [Canal](https://github.com/tigera/canal); with [Weave](http://www.weave.works/) indicating support in the near future. Red Hat’s OpenShift includes network policy features as well. +There are only a few policy-capable networking backends available for Kubernetes today: Romana, [Calico](http://projectcalico.org/), and [Canal](https://github.com/tigera/canal); with [Weave](http://www.weave.works/) indicating support in the near future. Red Hat’s OpenShift includes network policy features as well. @@ -100,7 +100,7 @@ This is because during a typical network performance benchmark, there’s no app - Hardware: Two servers with Intel Core i5-5250U CPUs (2 core, 2 threads per core) running at 1.60GHz, 16GB RAM and 512GB SSD. NIC: Intel Ethernet Connection I218-V (rev 03) - Ubuntu 14.04.5 - Kubernetes 1.3 for data collection (verified samples on [v1.4.0-beta.5](http://v1.4.0-beta.5/)) -- [Romana v0.9.3.1](https://github.com/romana/romana) +- Romana v0.9.3.1 - Client and server load test [software](https://github.com/paninetworks/testing-tools) For the tests we had a client pod send 2,000 HTTP requests to a server pod. HTTP requests were sent by the client pod at a rate that ensured that neither the server nor network ever saturated. We also made sure each request started a new TCP session by disabling persistent connections (i.e. HTTP [keep-alive](https://en.wikipedia.org/wiki/HTTP_persistent_connection)). We ran each test with different response sizes and measured the average request duration time (how long does it take to complete a request of that size). Finally, we repeated each set of measurements with different policy configurations. @@ -189,4 +189,4 @@ These tests were performed using Romana as the backend policy provider and other -If you wish to try it for yourself, we invite you to check out [Romana](https://github.com/romana/romana). In our [GitHub repo](https://github.com/romana/romana) you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster. +If you wish to try it for yourself, we invite you to check out Romana. In our GitHub repo you can find an easy to use installer, which works with AWS, Vagrant VMs or any other servers. You can use it to quickly get you started with a Romana powered Kubernetes or OpenStack cluster. diff --git a/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md b/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md index 44853d2567..181af0aa58 100644 --- a/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md +++ b/content/en/blog/_posts/2017-08-00-High-Performance-Networking-With-Ec2.md @@ -9,7 +9,7 @@ url: /blog/2017/08/High-Performance-Networking-With-Ec2 One of the most popular platforms for running Kubernetes is Amazon Web Services’ Elastic Compute Cloud (AWS EC2). With more than a decade of experience delivering IaaS, and expanding over time to include a rich set of services with easy to consume APIs, EC2 has captured developer mindshare and loyalty worldwide. -When it comes to networking, however, EC2 has some limits that hinder performance and make deploying Kubernetes clusters to production unnecessarily complex. The preview release of [Romana v2.0](https://github.com/romana/romana), a network and security automation solution for Cloud Native applications, includes features that address some well known network issues when running Kubernetes in EC2. +When it comes to networking, however, EC2 has some limits that hinder performance and make deploying Kubernetes clusters to production unnecessarily complex. The preview release of Romana v2.0, a network and security automation solution for Cloud Native applications, includes features that address some well known network issues when running Kubernetes in EC2. ## Traditional VPC Networking Performance Roadblocks @@ -40,7 +40,7 @@ Whether you were interested in advanced networking for traffic isolation or runn The way to avoid running out of VPC routes is to use them sparingly by making them forward pod traffic for multiple instances. From a networking perspective, what that means is that the VPC route needs to forward to a router, which can then forward traffic on to the final destination instance. -[Romana](https://github.com/romana/romana) is a CNI network provider that configures routes on the host to forward pod network traffic without an overlay. Since inter-node routes are installed on hosts, no VPC routes are necessary at all. However, when the VPC is split into subnets for an HA deployment across zones, VPC routes are necessary. +Romana is a CNI network provider that configures routes on the host to forward pod network traffic without an overlay. Since inter-node routes are installed on hosts, no VPC routes are necessary at all. However, when the VPC is split into subnets for an HA deployment across zones, VPC routes are necessary. Fortunately, inter-node routes on hosts allows them to act as a network router and forward traffic inbound from another zone just as it would for traffic from local pods. This makes any Kubernetes node configured by Romana able to accept inbound pod traffic from other zones and forward it to the proper destination node on the subnet. From e0143344e7deb4fa872920b43241817cbc5ed307 Mon Sep 17 00:00:00 2001 From: "Mr. Erlison" Date: Thu, 28 Apr 2022 10:30:54 -0300 Subject: [PATCH 036/827] Update sentence adjustment --- content/pt-br/docs/reference/glossary/sig.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/pt-br/docs/reference/glossary/sig.md b/content/pt-br/docs/reference/glossary/sig.md index 8d87706100..37d70a85f1 100644 --- a/content/pt-br/docs/reference/glossary/sig.md +++ b/content/pt-br/docs/reference/glossary/sig.md @@ -4,13 +4,13 @@ id: sig date: 2018-04-12 full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list short_description: > - Membros da comunidade que gerenciam coletivamente uma parte ou continuamente um projeto maior de código aberto do Kubernetes. + Membros da comunidade que gerenciam coletivamente e continuamente uma parte ou um projeto maior de código aberto do Kubernetes. aka: tags: - community --- - {{< glossary_tooltip text="Membros da comunidade" term_id="member" >}} que gerenciam coletivamente uma parte ou continuamente um projeto maior de código aberto do Kubernetes. + {{< glossary_tooltip text="Membros da comunidade" term_id="member" >}} que gerenciam coletivamente e continuamente uma parte ou um projeto maior de código aberto do Kubernetes. From 891014838ea7b100a25365613f099dfee9465be4 Mon Sep 17 00:00:00 2001 From: Jai Govindani Date: Tue, 3 May 2022 16:58:42 +0700 Subject: [PATCH 037/827] fix: Add quotes on annotation boolean Co-authored-by: divya-mohan0209 --- content/en/docs/reference/labels-annotations-taints/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index 9bb4ab12d8..64dc6182aa 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -349,7 +349,7 @@ Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassN ### storageclass.kubernetes.io/is-default-class -Example: `storageclass.kubernetes.io/is-default-class: true` +Example: `storageclass.kubernetes.io/is-default-class: "true"` Used on: StorageClass From 63272f93681a6679d6907a4b6f5f6717b9db9d6e Mon Sep 17 00:00:00 2001 From: Aldo Culquicondor Date: Fri, 6 May 2022 14:05:48 -0400 Subject: [PATCH 038/827] Accurate explanation for the calculation of number of failures in the Job API --- .../docs/concepts/workloads/controllers/job.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 74a232831a..ee84629f78 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -253,9 +253,19 @@ due to a logical error in configuration etc. To do so, set `.spec.backoffLimit` to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an -exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The -back-off count is reset when a Job's Pod is deleted or successful without any -other Pods for the Job failing around that time. +exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. + +The number of retries is calculated in two ways: +- The number of Pods with `.status.phase = "Failed"`. +- When using `restartPolicy = "OnFailure"`, the number of retries in all the + containers of Pods with `.status.phase` equal to `Pending` or `Running`. + +If either of the calculations reaches the `.spec.backoffLimit`, the Job is +considered failed. + +When the [`JobTrackingWithFinalizers`](#job-tracking-with-finalizers) feature is +disabled, the number of failed Pods is only based on Pods that are still present +in the API. {{< note >}} If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job @@ -405,7 +415,7 @@ The pattern names are also links to examples and more detailed description. | ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| | [Queue with Pod Per Work Item] | ✓ | | sometimes | | [Queue with Variable Pod Count] | ✓ | ✓ | | -| [Indexed Job with Static Work Assignment] | ✓ | | ✓ | +| [Indexed Job with Static Work Assignment] | ✓ | | ✓ | | [Job Template Expansion] | | | ✓ | When you specify completions with `.spec.completions`, each Pod created by the Job controller From 13860de7340e0996a2757b953d9fdfcb3412937a Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 9 May 2022 11:51:06 +0900 Subject: [PATCH 039/827] Fix links to ephemeral volume types --- content/en/docs/concepts/storage/volumes.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index cc9a9565eb..e55780912b 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -1166,8 +1166,8 @@ CSI driver. A `csi` volume can be used in a Pod in three different ways: * through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) -* with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) -* with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) +* with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) +* with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) if the driver supports that (beta feature) The following fields are available to storage administrators to configure a CSI @@ -1234,7 +1234,7 @@ You can set up your You can directly configure CSI volumes within the Pod specification. Volumes specified in this way are ephemeral and do not persist across pod restarts. See [Ephemeral -Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) +Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) for more information. For more information on how to develop a CSI driver, refer to the From a975ba2c1a3c1e1855ea176f0f61e2c95ff874ab Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 9 May 2022 14:11:33 +0900 Subject: [PATCH 040/827] [ko] Update links in dev-1.24-ko.1 --- .../services-networking/service-topology.md | 2 +- .../service-traffic-policy.md | 2 +- content/ko/docs/concepts/storage/volumes.md | 18 ++++++++++-------- .../feature-gates.md | 4 ++-- content/ko/docs/tutorials/_index.md | 4 ++-- .../tutorials/security/cluster-level-pss.md | 2 +- 6 files changed, 17 insertions(+), 15 deletions(-) diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index 8814c772c7..898daa7853 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -16,7 +16,7 @@ weight: 10 이 기능, 특히 알파 `topologyKeys` API는 쿠버네티스 v1.21부터 더 이상 사용되지 않는다. -쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints/)는 +쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)는 유사한 기능을 제공한다. {{}} diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index 34e6b3df39..7696657c65 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 ## {{% heading "whatsnext" %}} -* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 +* [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index ea5b9ed25e..4ce85817f5 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -881,6 +881,8 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 `adminSecretName` 값이 `adminId` 파라미터 값의 base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. +{{< /note >}} + ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1196,10 +1198,10 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 `csi` 볼륨은 세 가지 방법으로 파드에서 사용할 수 있다. * [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서 -* [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 -(알파 기능) +* [일반 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)과 함께 + (알파 기능) * 드라이버가 지원하는 경우 -[CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)과 함께 (베타 기능) + [CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)과 함께 (베타 기능) 스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 구성할 수 있다. @@ -1262,11 +1264,11 @@ CSI 설정 변경 없이 평소와 같이 {{< feature-state for_k8s_version="v1.16" state="beta" >}} -파드 명세 내에서 CSI 볼륨을 직접 구성할 수 -있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며 -파드가 다시 시작할 때 지속되지 않는다. 자세한 내용은 [임시 -볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)을 -참고한다. +파드 명세 내에서 CSI 볼륨을 직접 구성할 수 있다. +이 방식으로 지정된 볼륨은 임시 볼륨이며 +파드가 다시 시작할 때 지속되지 않는다. +자세한 내용은 +[임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)을 참고한다. CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index b39ea38292..5f31d10efa 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -809,7 +809,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). - [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다. + [임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/)을 참고한다. - `GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행 중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 @@ -1064,7 +1064,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 서비스 어카운트 토큰을 파드에 주입할 수 있다. - `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반 토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은 - [토폴로지 어웨어 힌트](/docs/concepts/services-networking/topology-aware-hints/) + [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/) 를 참고한다. - `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index c929b54196..4b708f68fe 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -53,8 +53,8 @@ content_type: concept ## 보안 -* [파드 보안 표준을 클러스터 수준으로 적용하기](/docs/tutorials/security/cluster-level-pss/) -* [파드 보안 표준을 네임스페이스 수준으로 적용하기](/docs/tutorials/security/ns-level-pss/) +* [파드 보안 표준을 클러스터 수준으로 적용하기](/ko/docs/tutorials/security/cluster-level-pss/) +* [파드 보안 표준을 네임스페이스 수준으로 적용하기](/ko/docs/tutorials/security/ns-level-pss/) * [AppArmor](/ko/docs/tutorials/security/apparmor/) * [seccomp](/docs/tutorials/security/seccomp/) ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/tutorials/security/cluster-level-pss.md b/content/ko/docs/tutorials/security/cluster-level-pss.md index 75213a745b..baa0a6ec05 100644 --- a/content/ko/docs/tutorials/security/cluster-level-pss.md +++ b/content/ko/docs/tutorials/security/cluster-level-pss.md @@ -229,7 +229,7 @@ weight: 10 # default false selinuxRelabel: false # optional: set propagation mode (None, HostToContainer or Bidirectional) - # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation + # see https://kubernetes.io/ko/docs/concepts/storage/volumes/#마운트-전파-propagation # default None propagation: None EOF From 5770779f15f783b280ccd6e756128e812b5e02f3 Mon Sep 17 00:00:00 2001 From: Sarang Joshi Date: Mon, 9 May 2022 14:32:55 -0700 Subject: [PATCH 041/827] Update ports-and-protocols.md --- content/en/docs/reference/ports-and-protocols.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/ports-and-protocols.md b/content/en/docs/reference/ports-and-protocols.md index 91d6cba8e7..8ca5bc0774 100644 --- a/content/en/docs/reference/ports-and-protocols.md +++ b/content/en/docs/reference/ports-and-protocols.md @@ -7,7 +7,7 @@ weight: 50 When running Kubernetes in an environment with strict network boundaries, such as on-premises datacenter with physical network firewalls or Virtual Networks in Public Cloud, it is useful to be aware of the ports and protocols -used by Kubernetes components +used by Kubernetes components. ## Control plane From f875adcb500325a1911c8cdb6cb883f51b8d7b96 Mon Sep 17 00:00:00 2001 From: James Sturtevant Date: Fri, 29 Apr 2022 10:55:13 -0700 Subject: [PATCH 042/827] Refresh kubeadm docs for Windows --- .../tools/kubeadm/create-cluster-kubeadm.md | 4 + .../kubeadm/adding-windows-nodes.md | 256 ------------------ .../kubeadm/upgrading-windows-nodes.md | 27 +- 3 files changed, 20 insertions(+), 267 deletions(-) delete mode 100644 content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index d7897dfec5..d70056e71f 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -336,6 +336,10 @@ The nodes are where your workloads (containers and Pods, etc) run. To add new no kubeadm join --token : --discovery-token-ca-cert-hash sha256: ``` +{{< note >}} +On Windows you should specify the `--cri-socket` parameter in the `kubeadm join` command. The default path is "npipe:////./pipe/containerd-containerd" for containerd. +{{< /note >}} + If you do not have the token, you can get it by running the following command on the control-plane node: ```bash diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md deleted file mode 100644 index 30dd5c4cb0..0000000000 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ /dev/null @@ -1,256 +0,0 @@ ---- -reviewers: -- jayunit100 -- jsturtevant -- marosset -- perithompson -title: Adding Windows nodes -min-kubernetes-server-version: 1.17 -content_type: tutorial -weight: 30 ---- - - - -{{< feature-state for_k8s_version="v1.18" state="beta" >}} - -You can use Kubernetes to run a mixture of Linux and Windows nodes, so you can mix Pods that run on Linux on with Pods that run on Windows. This page shows how to register Windows nodes to your cluster. - - -## {{% heading "prerequisites" %}} - {{< version-check >}} - -* Obtain a [Windows Server 2019 license](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) -(or higher) in order to configure the Windows node that hosts Windows containers. -If you are using VXLAN/Overlay networking you must have also have [KB4489899](https://support.microsoft.com/help/4489899) installed. - -* A Linux-based Kubernetes kubeadm cluster in which you have access to the control plane (see [Creating a single control-plane cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)). - - - - -## {{% heading "objectives" %}} - - -* Register a Windows node to the cluster -* Configure networking so Pods and Services on Linux and Windows can communicate with each other - - - - - - -## Getting Started: Adding a Windows Node to Your Cluster - -### Networking Configuration - -Once you have a Linux-based Kubernetes control-plane node you are ready to choose a networking solution. This guide illustrates using Flannel in VXLAN mode for simplicity. - -#### Configuring Flannel - -1. Prepare Kubernetes control plane for Flannel - - Some minor preparation is recommended on the Kubernetes control plane in our cluster. It is recommended to enable bridged IPv4 traffic to iptables chains when using Flannel. The following command must be run on all Linux nodes: - - ```bash - sudo sysctl net.bridge.bridge-nf-call-iptables=1 - ``` - -1. Download & configure Flannel for Linux - - Download the most recent Flannel manifest: - - ```bash - wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml - ``` - - Modify the `net-conf.json` section of the flannel manifest in order to set the VNI to 4096 and the Port to 4789. It should look as follows: - - ```json - net-conf.json: | - { - "Network": "10.244.0.0/16", - "Backend": { - "Type": "vxlan", - "VNI": 4096, - "Port": 4789 - } - } - ``` - - {{< note >}}The VNI must be set to 4096 and port 4789 for Flannel on Linux to interoperate with Flannel on Windows. See the [VXLAN documentation](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). - for an explanation of these fields.{{< /note >}} - - {{< note >}}To use L2Bridge/Host-gateway mode instead change the value of `Type` to `"host-gw"` and omit `VNI` and `Port`.{{< /note >}} - -1. Apply the Flannel manifest and validate - - Let's apply the Flannel configuration: - - ```bash - kubectl apply -f kube-flannel.yml - ``` - - After a few minutes, you should see all the pods as running if the Flannel pod network was deployed. - - ```bash - kubectl get pods -n kube-system - ``` - - The output should include the Linux flannel DaemonSet as running: - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - ... - kube-system kube-flannel-ds-54954 1/1 Running 0 1m - ``` - -1. Add Windows Flannel and kube-proxy DaemonSets - - Now you can add Windows-compatible versions of Flannel and kube-proxy. In order - to ensure that you get a compatible version of kube-proxy, you'll need to substitute - the tag of the image. The following example shows usage for Kubernetes {{< param "fullversion" >}}, - but you should adjust the version for your own deployment. - - ```bash - curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - - kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml - ``` - {{< note >}} - If you're using host-gateway use https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml instead - {{< /note >}} - - {{< note >}} -If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: - -```powershell -wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" -``` - -in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly. - -```bash -# Example -curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - -``` - {{< /note >}} - - - -### Joining a Windows worker node - -{{< note >}} -All code snippets in Windows sections are to be run in a PowerShell environment -with elevated permissions (Administrator) on the Windows worker node. -{{< /note >}} - -{{< tabs name="tab-windows-kubeadm-runtime-installation" >}} - -{{% tab name="CRI-containerD" %}} - -#### Install containerD - -```powershell -curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1 -.\Install-Containerd.ps1 -``` - -{{< note >}} -To install a specific version of containerD specify the version with -ContainerDVersion. - -```powershell -# Example -.\Install-Containerd.ps1 -ContainerDVersion 1.4.1 -``` - -If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, specify the name with `-netAdapterName`. - -```powershell -# Example -.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2" -``` - -{{< /note >}} - -#### Install wins, kubelet, and kubeadm - -```PowerShell -curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 -.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD -``` - -Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools) -which is required so that kubeadm can talk to the CRI endpoint. - -#### Run `kubeadm` to join the node - -Use the command that was given to you when you ran `kubeadm init` on a control plane host. -If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command` -(on a control plane host) to generate a new token and join command. - -{{% /tab %}} - -{{% tab name="Docker Engine" %}} - -#### Install Docker Engine - -Install the `Containers` feature - -```powershell -Install-WindowsFeature -Name containers -``` - -Install Docker -Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker). - -[Install cri-dockerd](https://github.com/Mirantis/cri-dockerd) which is required so that the kubelet -can communicate with Docker on a CRI compatible endpoint. - -{{< note >}} -Docker Engine does not implement the [CRI](/docs/concepts/architecture/cri/) -which is a requirement for a container runtime to work with Kubernetes. -For that reason, an additional service [cri-dockerd](https://github.com/Mirantis/cri-dockerd) -has to be installed. cri-dockerd is a project based on the legacy built-in -Docker Engine support that was [removed](/dockershim) from the kubelet in version 1.24. -{{< /note >}} - -Install `crictl` from the [cri-tools project](https://github.com/kubernetes-sigs/cri-tools) -which is required so that kubeadm can talk to the CRI endpoint. - -#### Install wins, kubelet, and kubeadm - -```PowerShell -curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 -.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -``` - -#### Run `kubeadm` to join the node - -Use the command that was given to you when you ran `kubeadm init` on a control plane host. -If you no longer have this command, or the token has expired, you can run `kubeadm token create --print-join-command` -(on a control plane host) to generate a new token and join command. - -{{% /tab %}} - -{{< /tabs >}} - -### Verifying your installation - -You should now be able to view the Windows node in your cluster by running: - -```bash -kubectl get nodes -o wide -``` - -If your new node is in the `NotReady` state it is likely because the flannel image is still downloading. -You can check the progress as before by checking on the flannel pods in the `kube-system` namespace: - -```shell -kubectl -n kube-system get pods -l app=flannel -``` - -Once the flannel Pod is running, your node should enter the `Ready` state and then be available to handle workloads. - -## {{% heading "whatsnext" %}} - -- [Upgrading Windows kubeadm nodes](/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md index 35857d09a0..9efe6d8c2f 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes.md @@ -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 C:\k\kubeadm.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe + curl.exe -Lo https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubeadm.exe ``` ### Drain the node @@ -62,16 +62,28 @@ upgrade the control plane nodes before upgrading your Windows nodes. kubeadm upgrade node ``` -### Upgrade kubelet +### Upgrade kubelet and kubeproxy 1. From the Windows node, upgrade and restart the kubelet: ```powershell stop-service kubelet - curl.exe -Lo C:\k\kubelet.exe https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe + curl.exe -Lo https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubelet.exe restart-service kubelet ``` +2. From the Windows node, upgrade and restart the kube-proxy. + + ```powershell + stop-service kube-proxy + curl.exe -Lo https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kube-proxy.exe + restart-service kube-proxy + ``` + +{{< note >}} +If you are running kube-proxy in a HostProcess Container instead of a Windows Service, you can upgrade kube-proxy by applying a newer version of your kube-proxy manifests. +{{< /note >}} + ### Uncordon the node 1. From a machine with access to the Kubernetes API, @@ -81,14 +93,7 @@ bring the node back online by marking it schedulable: # replace with the name of your node kubectl uncordon ``` -### Upgrade kube-proxy - -1. From a machine with access to the Kubernetes API, run the following, -again replacing {{< param "fullversion" >}} with your desired version: - - ```shell - curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/{{< param "fullversion" >}}/g' | kubectl apply -f - - ``` + From 002866f6e2dfafcf162af035aeb05dfd655226c5 Mon Sep 17 00:00:00 2001 From: Haneul Lee Date: Wed, 11 May 2022 10:40:24 +0900 Subject: [PATCH 043/827] [ko] fix grammar at tutorials-basics-explore --- .../tutorials/kubernetes-basics/explore/explore-intro.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html index e218222010..c09d8c014e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -74,7 +74,7 @@ weight: 10

노드

-

파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 컨트롤 플레인에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려합니다.

+

파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 컨트롤 플레인에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려한다.

모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.

    @@ -85,7 +85,7 @@ weight: 10
-

만약 컨테이너들이 밀접하고 결합되어 있고 디스크와 같은 자원을 공유해야 한다면 오직 하나의 단일 파드에 함께 스케쥴되어져야 한다.

+

만약 컨테이너들이 밀접하게 결합되어 있고 디스크와 같은 자원을 공유해야 한다면 오직 하나의 단일 파드에 함께 스케쥴되어져야 한다.

From e21eafb9e84a799ee8ced7e6803b27a769a43f11 Mon Sep 17 00:00:00 2001 From: Sudheer Satyanarayana Date: Wed, 11 May 2022 19:02:37 +0530 Subject: [PATCH 044/827] Update chart link The currently used chart is not maintained anymore. Using Bitnami chart is recommended instead. The PR updates the link to the correct chart. --- .../stateful-application/mysql-wordpress-persistent-volume.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index e5f32633e3..d3c426d789 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -16,7 +16,7 @@ This tutorial shows you how to deploy a WordPress site and a MySQL database usin A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. {{< warning >}} -This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production. +This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress) to deploy WordPress in production. {{< /warning >}} {{< note >}} From ffb5e67cc5e4082069dafc516b6f363b6ce20eee Mon Sep 17 00:00:00 2001 From: Eirik A Date: Thu, 12 May 2022 19:57:59 +0100 Subject: [PATCH 045/827] Add kube-rs to operator.md's third-party content We have a [controller guide featured](https://kube.rs/controllers/intro/) on the linked webpage for this so hopefully this is appropriate. --- content/en/docs/concepts/extend-kubernetes/operator.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index 96a17ada96..772c6a5572 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -112,6 +112,7 @@ Operator. * [Charmed Operator Framework](https://juju.is/) * [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 operator SDK) * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) From 9d08cafd2bae670c10a63b70fcb1c9e9a9854f5e Mon Sep 17 00:00:00 2001 From: Michele Azzolari Date: Sat, 14 May 2022 10:45:09 +0200 Subject: [PATCH 046/827] Update Validation Rules Example Fix example add missing `=` Add one more example --- .../custom-resources/custom-resource-definitions.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index cfe5cb2ad4..93fc8266ed 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -811,7 +811,7 @@ Validation Rules Examples: | `'Available' in self.stateCounts` | Validate that an entry with the 'Available' key exists in a map | | `(size(self.list1) == 0) != (size(self.list2) == 0)` | Validate that one of two lists is non-empty, but not both | | !('MY_KEY' in self.map1) || self['MY_KEY'].matches('^[a-zA-Z]*$') | Validate the value of a map for a specific key, if it is in the map | -| `self.envars.filter(e, e.name = 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')` | Validate the 'value' field of a listMap entry where key field 'name' is 'MY_ENV' | +| `self.envars.filter(e, e.name == 'MY_ENV').all(e, e.value.matches('^[a-zA-Z]*$')` | Validate the 'value' field of a listMap entry where key field 'name' is 'MY_ENV' | | `has(self.expired) && self.created + self.ttl < self.expired` | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration | | `self.health.startsWith('ok')` | Validate a 'health' string field has the prefix 'ok' | | `self.widgets.exists(w, w.key == 'x' && w.foo < 10)` | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 | @@ -819,6 +819,7 @@ Validation Rules Examples: | `self.metadata.name.startsWith(self.prefix)` | Validate that an object's name has the prefix of another field value | | `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint | | `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet | +| `size(self.clusters.filter(c, c.name == self.primary)) == 1` | Validate that the 'primary' property has one and only one occurrence in the 'clusters' listMap | Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation) From 986a55ef971b73dba727cb933f4781bd271b7a71 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Tue, 17 May 2022 09:56:21 +0100 Subject: [PATCH 047/827] Fix blog article title Use the same article naming as the rest of the release comms series. --- content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md b/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md index 35d6838f51..2bb85059e3 100644 --- a/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md +++ b/content/en/blog/_posts/2022-05-06-storage-capacity-GA/index.md @@ -1,6 +1,6 @@ --- layout: blog -title: "Storage Capacity Tracking reaches GA in Kubernetes 1.24" +title: "Kubernetes 1.24: Storage Capacity Tracking Now Generally Available" date: 2022-05-06 slug: storage-capacity-ga --- From 2f15d185d5ed27ea8d5cf89d0c37d371f9fd0e90 Mon Sep 17 00:00:00 2001 From: Paul Bastide Date: Tue, 17 May 2022 09:33:30 -0400 Subject: [PATCH 048/827] Update pod-topology-spread-constraints.md The minDomains value was not included in the spec schema segment --- .../concepts/workloads/pods/pod-topology-spread-constraints.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 34ca33d6b1..9339c92add 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -64,6 +64,7 @@ metadata: spec: topologySpreadConstraints: - maxSkew: + minDomains: topologyKey: whenUnsatisfiable: labelSelector: From f55951852059c85ceca96369909b5dce0f43b51d Mon Sep 17 00:00:00 2001 From: eminalemdar Date: Thu, 19 May 2022 17:00:59 +0300 Subject: [PATCH 049/827] Updated references in different pages with the correct titles of the documents --- .../overview/working-with-objects/object-management.md | 6 +++--- .../tasks/manage-kubernetes-objects/imperative-command.md | 4 ++-- .../tasks/manage-kubernetes-objects/imperative-config.md | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/concepts/overview/working-with-objects/object-management.md b/content/en/docs/concepts/overview/working-with-objects/object-management.md index b85c622823..10b6dacf85 100644 --- a/content/en/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/en/docs/concepts/overview/working-with-objects/object-management.md @@ -169,9 +169,9 @@ Disadvantages compared to imperative object configuration: ## {{% heading "whatsnext" %}} - [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) -- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/) -- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/) -- [Managing Kubernetes Objects Using Kustomize (Declarative)](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [Declarative Management of Kubernetes Objects Using Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) - [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md index 8e0670a89f..07c631bc3a 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -165,8 +165,8 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} -* [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tasks/manage-kubernetes-objects/imperative-config/) -* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/) +* [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/) +* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md index 87cc423da7..4e59491c62 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -161,7 +161,7 @@ template: * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) -* [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tasks/manage-kubernetes-objects/declarative-config/) +* [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) From 17dc7c7e2feef495b6819c19448285c7dd5005cc Mon Sep 17 00:00:00 2001 From: Mark Rossetti Date: Thu, 19 May 2022 14:46:01 -0700 Subject: [PATCH 050/827] Add troubleshooting tips for hostprocess containers 'failed to create user process token' error during container creation Signed-off-by: Mark Rossetti --- .../configure-pod-container/create-hostprocess-pod.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md index a7dcbafd34..ed5506c45b 100644 --- a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md +++ b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md @@ -214,3 +214,10 @@ container, aiming to limit the degree of privileges so as to avoid accidental (o malicious) damage to the host. The LocalSystem service account has the highest level of privilege of the three and should be used only if absolutely necessary. Where possible, use the LocalService service account as it is the least privileged of the three options. + +## Troubleshooting HostProcess containers + +- HostProcess containers fail to start with `failed to create user process token: failed to logon user: Access is denied.: unknown` + + Ensure containerd is running as `LocalSystem` or `LocalService` service accounts. User accounts (even Administrator accounts) do not have permissions to create logon tokens for any of the supported [user accounts](#choosing-a-user-account). + \ No newline at end of file From 34140f10872eed1750e31f09ebd16b7e28bf5ea2 Mon Sep 17 00:00:00 2001 From: Fabrice Jammes Date: Fri, 20 May 2022 16:38:22 +0200 Subject: [PATCH 051/827] Update socks5-proxy-access-api.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit If using `localhost` instead of , you get a certificate error: ``` kubectl get pods I0520 16:29:08.178277 41261 versioner.go:58] Get https://localhost:6443/version?timeout=5s: dial tcp 127.0.0.1:6443: connect: connection refused Unable to connect to the server: x509: certificate is valid for ccqserv225, kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, not localhost ``` Please also note that I have a warning message if I unset the `https_proxy` env variable: ``` ⚙ kubectl get pods I0520 16:35:27.955076 43865 versioner.go:56] Remote kubernetes server unreachable NAME READY STATUS RESTARTS AGE hub-54c6457f66-vlq2l 1/1 Running 0 4h27m proxy-7b5b8dfb9d-dxrkz 1/1 Running 0 4h27m # Whereas with the https_proxy variable: ⚙ export https_proxy=socks5://localhost:1080 ⚙ kubectl get pods NAME READY STATUS RESTARTS AGE hub-54c6457f66-vlq2l 1/1 Running 0 4h28m proxy-7b5b8dfb9d-dxrkz 1/1 Running 0 4h28m ``` Any idea is welcome here. --- .../tasks/extend-kubernetes/socks5-proxy-access-api.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/tasks/extend-kubernetes/socks5-proxy-access-api.md b/content/en/docs/tasks/extend-kubernetes/socks5-proxy-access-api.md index 698bc9c6b4..a785c5d91a 100644 --- a/content/en/docs/tasks/extend-kubernetes/socks5-proxy-access-api.md +++ b/content/en/docs/tasks/extend-kubernetes/socks5-proxy-access-api.md @@ -87,14 +87,14 @@ When you set the `https_proxy` variable, tools such as `curl` route HTTPS traffi you configured. For this to work, the tool must support SOCKS5 proxying. {{< note >}} -In the URL https://localhost/api, `localhost` does not refer to your local client computer. +In the URL https://localhost:6443/api, `localhost` does not refer to your local client computer. Instead, it refers to the endpoint on the remote server knows as `localhost`. The `curl` tool sends the hostname from the HTTPS URL over SOCKS, and the remote server resolves that locally (to an address that belongs to its loopback interface). {{}} ```shell -curl -k -v https://localhost/api +curl -k -v https://localhost:6443/api ``` To use the official Kubernetes client `kubectl` with a proxy, set the `proxy-url` element @@ -105,7 +105,7 @@ apiVersion: v1 clusters: - cluster: certificate-authority-data: LRMEMMW2 # shortened for readability - server: https://localhost # the "Kubernetes API" in the diagram above + server: https://:6443 # the "Kubernetes API" server, i.e. IP adress of kubernetes-remote-server.example proxy-url: socks5://localhost:1080 # the "SSH SOCKS5 proxy" in the diagram above (DNS resolution over socks is built-in) name: default contexts: @@ -142,4 +142,4 @@ Type `unset https_proxy` in a terminal to stop forwarding http traffic through t ## Further reading -* [OpenSSH remote login client](https://man.openbsd.org/ssh) \ No newline at end of file +* [OpenSSH remote login client](https://man.openbsd.org/ssh) From 31b677f5187f73d3fa34bbbe731ce409060dc452 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 24 May 2022 18:28:06 +0900 Subject: [PATCH 052/827] [ko] Update outdated files in dev-1.24-ko.1 M32-M33 --- .../scheduling-eviction/api-eviction.md | 118 ++++- .../scheduling-eviction/assign-pod-node.md | 484 ++++++++++-------- 2 files changed, 370 insertions(+), 232 deletions(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md index 45077a6674..8368be9831 100644 --- a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md @@ -1,18 +1,122 @@ --- -title: API를 이용한 축출(Eviction) +title: API를 이용한 축출(API-initiated Eviction) content_type: concept weight: 70 --- {{< glossary_definition term_id="api-eviction" length="short" >}}
-`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여, -축출 API를 직접 호출해 축출 요청을 할 수 있다. -그러면 API 서버가 파드를 종료하는 `Eviction` 오브젝트가 생성된다. +축출 API를 직접 호출하거나, 또는 `kubectl drain` 명령과 같이 +{{}}의 클라이언트를 사용하여 프로그램적인 방법으로 축출 요청을 할 수 있다. +이는 `Eviction` 오브젝트를 만들며, API 서버로 하여금 파드를 종료하도록 만든다. -API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 [`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 준수한다. +API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 +[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다. + +API를 사용하여 `Eviction` 오브젝트를 만드는 것은 +정책 기반의 파드 [`DELETE` 동작](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)을 수행하는 것과 +비슷한 효과를 낸다. + +## 축출 API 호출하기 + +[각 언어 별 쿠버네티스 클라이언트](/ko/docs/tasks/administer-cluster/access-cluster-api/#api에-프로그래밍-방식으로-접근)를 사용하여 +쿠버네티스 API를 호출하고 `Eviction` 오브젝트를 생성할 수 있다. +이를 실행하려면, 아래의 예시를 참고하여 POST 호출을 수행한다. + +{{< tabs name="Eviction_example" >}} +{{% tab name="policy/v1" %}} +{{< note >}} +`policy/v1` 축출은 v1.22 이상에서 사용 가능하다. 이전 버전에서는 `policy/v1beta1`를 사용한다. +{{< /note >}} + +```json +{ + "apiVersion": "policy/v1", + "kind": "Eviction", + "metadata": { + "name": "quux", + "namespace": "default" + } +} +``` +{{% /tab %}} +{{% tab name="policy/v1beta1" %}} +{{< note >}} +v1.22에서 사용 중단 및 `policy/v1`으로 대체되었다. +{{< /note >}} + +```json +{ + "apiVersion": "policy/v1beta1", + "kind": "Eviction", + "metadata": { + "name": "quux", + "namespace": "default" + } +} +``` +{{% /tab %}} +{{< /tabs >}} + +또는 다음 예시와 같이 `curl` 또는 `wget`으로 API에 접근하여 +축출 동작을 시도할 수도 있다. + +```bash +curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json +``` + +## API를 이용한 축출의 동작 + +API를 사용하여 축출을 요청하면, +API 서버는 인가 확인(admission checks)를 수행하고 다음 중 하나로 응답한다. + +* `200 OK`: 축출 요청이 허용되었고, `Eviction` 서브리소스가 생성되었고, + (마치 파드 URL에 `DELETE` 요청을 보낸 것처럼) 파드가 삭제되었다. +* `429 Too Many Requests`: 현재 설정된 + {{}} 때문에 + 축출이 현재 허용되지 않는다. + 또는 API 요청 속도 제한(rate limiting) 때문에 이 응답을 받았을 수도 있다. +* `500 Internal Server Error`: 잘못된 환경 설정(예: + 여러 PodDisruptionBudget이 하나의 동일한 파드를 참조함)으로 인해 축출이 허용되지 않는다. + +축출하려는 파드가 +PodDisruptionBudget이 설정된 워크로드에 속하지 않는다면, +API 서버는 항상 `200 OK`를 반환하고 축출을 허용한다. + +API 서버가 축출을 허용하면, 파드는 다음과 같이 삭제된다. + +1. API 서버 내 `Pod` 리소스의 삭제 타임스탬프(deletion timestamp)가 업데이트되며, + 이 타임스탬프에 명시된 시각이 경과하면 API 서버는 해당 `Pod` 리소스를 종료 대상으로 간주한다. + 또한 설정된 그레이스 시간(grace period)이 `Pod` 리소스에 기록된다. +1. 로컬 파드가 실행되고 있는 노드의 {{}}이 + `Pod`가 종료 대상으로 표시된 것을 감지하고 + 로컬 파드의 그레이스풀 셧다운을 시작한다. +1. kubelet이 파드를 종료하는 와중에, 컨트롤 플레인은 + {{}} 및 + {{}} 오브젝트에서 파드를 삭제한다. + 이 결과, 컨트롤러는 파드를 더 이상 유효한 오브젝트로 간주하지 않는다. +1. 파드의 그레이스 시간이 만료되면, + kubelet이 로컬 파드를 강제로 종료한다. +1. kubelet이 API 서버에 `Pod` 리소스를 삭제하도록 지시한다. +1. API 서버가 `Pod` 리소스를 삭제한다. + +## 문제가 있어 중단된 축출 트러블슈팅하기 + +일부 경우에, 애플리케이션이 잘못된 상태로 돌입하여, +직접 개입하기 전에는 축출 API가 `429` 또는 `500` 응답만 반환할 수 있다. +이러한 현상은, 예를 들면 레플리카셋이 애플리케이션을 서비스할 파드를 생성했지만 +새 파드가 `Ready`로 바뀌지 못하는 경우에 발생할 수 있다. +또는 마지막으로 축출된 파드가 긴 종료 그레이스 시간을 가진 경우에 이러한 현상을 목격할 수도 있다. + +문제가 있어 중단된 축출을 발견했다면, 다음 해결책 중 하나를 시도해 본다. + +* 이 문제를 발생시키는 자동 동작(automated operation)을 중단하거나 일시 중지한다. + 해당 동작을 재시작하기 전에, 문제가 있어 중단된 애플리케이션을 조사한다. +* 잠시 기다린 뒤, 축출 API를 사용하는 것 대신 + 클러스터 컨트롤 플레인에서 파드를 직접 삭제한다. ## {{% heading "whatsnext" %}} -- [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기 -- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기 +* [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/)을 사용하여 애플리케이션을 보호하는 방법에 대해 알아본다. +* [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 알아본다. +* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아본다. diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index 494d3b1601..771ebc483a 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -15,159 +15,182 @@ weight: 20 {{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다. 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다. -보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 -노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만 -간혹 파드가 배포될 노드를 제어해야 하는 경우가 있다. -예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 -동일한 가용성 영역(availability zone)에 배치할 수 있다. - +보통은 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 +노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건은 필요하지 않다. +그러나, 예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 +많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우와 같이, +파드가 어느 노드에 배포될지를 제어해야 하는 경우도 있다. -## 노드 셀렉터(nodeSelector) +쿠버네티스가 특정 파드를 어느 노드에 스케줄링할지 고르는 +다음의 방법 중 하나를 골라 사용할 수 있다. -`nodeSelector` 는 가장 간단하고 권장되는 노드 선택 제약 조건의 형태이다. -`nodeSelector` 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다. 파드가 노드에서 동작할 수 있으려면, -노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다). -일반적으로 하나의 키-값 쌍이 사용된다. + * [노드 레이블](#built-in-node-labels)에 매칭되는 [nodeSelector](#nodeselector) 필드 + * [어피니티 / 안티 어피니티](#affinity-and-anti-affinity) + * [nodeName](#nodename) 필드 -`nodeSelector` 를 어떻게 사용하는지 예시를 통해 알아보도록 하자. +## 노드 레이블 {#built-in-node-labels} -### 0 단계: 사전 준비 +다른 쿠버네티스 오브젝트와 마찬가지로, 노드도 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 가진다. +[레이블을 수동으로 추가](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/#노드에-레이블-추가)할 수 있다. +또한 쿠버네티스도 클러스터의 모든 노드에 표준화된 레이블 집합을 적용한다. +[잘 알려진 레이블, 어노테이션, 테인트](/ko/docs/reference/labels-annotations-taints/)에서 널리 사용되는 노드 레이블의 목록을 확인한다. -이 예시는 쿠버네티스 파드에 대한 기본적인 이해를 하고 있고 [쿠버네티스 클러스터가 설정](/ko/docs/setup/)되어 있다고 가정한다. +{{}} +이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다. +예를 들어, `kubernetes.io/hostname`에 대한 값은 특정 환경에서는 노드 이름과 동일할 수 있지만 +다른 환경에서는 다른 값일 수도 있다. +{{}} -### 1 단계: 노드에 레이블 붙이기 +### 노드 격리/제한 {#node-isolation-restriction} -`kubectl get nodes` 를 실행해서 클러스터 노드 이름을 가져온다. 이 중에 레이블을 추가하기 원하는 것 하나를 선택한 다음에 `kubectl label nodes <노드 이름> <레이블 키>=<레이블 값>` 을 실행해서 선택한 노드에 레이블을 추가한다. 예를 들어 노드의 이름이 'kubernetes-foo-node-1.c.a-robinson.internal' 이고, 원하는 레이블이 'disktype=ssd' 라면, `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 를 실행한다. +노드에 레이블을 추가하여 +파드를 특정 노드 또는 노드 그룹에 스케줄링되도록 지정할 수 있다. +이 기능을 사용하여 특정 파드가 특정 격리/보안/규제 속성을 만족하는 노드에서만 +실행되도록 할 수 있다. -`kubectl get nodes --show-labels` 를 다시 실행해서 노드가 현재 가진 레이블을 확인하여, 이 작업을 검증할 수 있다. 또한 `kubectl describe node "노드 이름"` 을 사용해서 노드에 주어진 레이블의 전체 목록을 확인할 수 있다. +노드 격리를 위해 레이블을 사용할 때, {{}}이 변경할 수 없는 레이블 키를 선택한다. +그렇지 않으면 kubelet이 해당 레이블을 변경하여 노드가 사용 불가능(compromised) 상태로 빠지고 +스케줄러가 이 노드에 워크로드를 스케줄링하는 일이 발생할 수 있다. -### 2 단계: 파드 설정에 nodeSelector 필드 추가하기 +[`NodeRestriction` 어드미션 플러그인](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)은 +kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 +설정하거나 변경하지 못하도록 한다. -실행하고자 하는 파드의 설정 파일을 가져오고, 이처럼 nodeSelector 섹션을 추가한다. 예를 들어 이것이 파드 설정이라면, +노드 격리를 위해 레이블 접두사를 사용하려면, -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: nginx - labels: - env: test -spec: - containers: - - name: nginx - image: nginx -``` +1. [노드 인가자(authorizer)](/docs/reference/access-authn-authz/node/)를 사용하고 있는지, 그리고 `NodeRestriction` 어드미션 플러그인을 **활성화** 했는지 확인한다. +1. 노드에 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 추가하고, [노드 셀렉터](#nodeselector)에서 해당 레이블을 사용한다. + 예: `example.com.node-restriction.kubernetes.io/fips=true` 또는 `example.com.node-restriction.kubernetes.io/pci-dss=true` -이 다음에 nodeSelector 를 다음과 같이 추가한다. +## 노드셀렉터(nodeSelector) {#nodeselector} -{{< codenew file="pods/pod-nginx.yaml" >}} +`nodeSelector`는 노드 선택 제약사항의 가장 간단하면서도 추천하는 형태이다. +파드 스펙에 `nodeSelector` 필드를 추가하고, +타겟으로 삼고 싶은 노드가 갖고 있는 [노드 레이블](#built-in-node-labels)을 명시한다. +쿠버네티스는 사용자가 명시한 레이블을 갖고 있는 노드에만 +파드를 스케줄링한다. -그런 다음에 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 을 -실행하면, 레이블이 붙여진 노드에 파드가 스케줄된다. -`kubectl get pods -o wide` 를 실행해서 파드가 할당된 -"NODE" 를 보면 작동하는지 검증할 수 있다. +[노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes)에서 +더 많은 정보를 확인한다. -## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels} +## 어피니티(affinity)와 안티-어피니티(anti-affinity) {#affinity-and-anti-affinity} -[붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는 -표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다. +`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 가장 간단한 방법이다. +어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. +주요 개선 사항은 다음과 같다. -{{< note >}} -이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다. -예를 들어 `kubernetes.io/hostname` 은 어떤 환경에서는 노드 이름과 같지만, -다른 환경에서는 다른 값일 수 있다. -{{< /note >}} +* 어피니티/안티-어피니티 언어가 더 표현적이다. + `nodeSelector`로는 명시한 레이블이 있는 노드만 선택할 수 있다. + 어피니티/안티-어피니티는 선택 로직에 대한 좀 더 많은 제어권을 제공한다. +* 규칙이 "소프트(soft)" 또는 "선호사항(preference)" 임을 나타낼 수 있으며, + 이 덕분에 스케줄러는 매치되는 노드를 찾지 못한 경우에도 파드를 스케줄링할 수 있다. +* 다른 노드 (또는 다른 토폴로지 도메인)에서 실행 중인 + 다른 파드의 레이블을 사용하여 파드를 제한할 수 있으며, + 이를 통해 어떤 파드들이 노드에 함께 위치할 수 있는지에 대한 규칙을 정의할 수 있다. -## 노드 격리(isolation)/제한(restriction) +어피니티 기능은 다음의 두 가지 종류로 구성된다. -노드 오브젝트에 레이블을 추가하면 파드가 특정 노드 또는 노드 그룹을 목표 대상으로 할 수 있게 된다. -이는 특정 파드가 어떤 격리, 보안, 또는 규제 속성이 있는 노드에서만 실행되도록 사용할 수 있다. -이 목적으로 레이블을 사용하는 경우, 노드에서 kubelet 프로세스로 수정할 수 없는 레이블 키를 선택하는 것을 권장한다. -이렇게 하면 손상된 노드가 해당 kubelet 자격 증명을 사용해서 해당 레이블을 자체 노드 오브젝트에 설정하고, -스케줄러가 손상된 노드로 워크로드를 스케줄 하는 것을 방지할 수 있다. +* *노드 어피니티* 기능은 `nodeSelector` 필드와 비슷하지만 + 더 표현적이고 소프트(soft) 규칙을 지정할 수 있게 해 준다. +* *파드 간 어피니티/안티-어피니티* 는 다른 파드의 레이블을 이용하여 + 해당 파드를 제한할 수 있게 해 준다. -`NodeRestriction` 어드미션 플러그인은 kubelet이 `node-restriction.kubernetes.io/` 접두사로 레이블을 설정 또는 수정하지 못하게 한다. -노드 격리에 해당 레이블 접두사를 사용하려면 다음과 같이 한다. +### 노드 어피니티 {#node-affinity} -1. [노드 권한부여자](/docs/reference/access-authn-authz/node/)를 사용하고 있고, [NodeRestriction 어드미션 플러그인](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)을 _활성화_ 해야 한다. -2. 노드 오브젝트의 `node-restriction.kubernetes.io/` 접두사 아래에 레이블을 추가하고, 해당 레이블을 노드 셀렉터에서 사용한다. -예를 들어, `example.com.node-restriction.kubernetes.io/fips=true` 또는 `example.com.node-restriction.kubernetes.io/pci-dss=true` 이다. +노드 어피니티는 개념적으로 `nodeSelector` 와 비슷하며, +노드의 레이블을 기반으로 파드가 스케줄링될 수 있는 노드를 제한할 수 있다. +노드 어피니티에는 다음의 두 종류가 있다. -## 어피니티(affinity)와 안티-어피니티(anti-affinity) + * `requiredDuringSchedulingIgnoredDuringExecution`: + 규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다. + 이 기능은 `nodeSelector`와 유사하지만, 좀 더 표현적인 문법을 제공한다. + * `preferredDuringSchedulingIgnoredDuringExecution`: + 스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. + 해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링한다. -`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다. -어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다. +{{}} +앞의 두 유형에서, `IgnoredDuringExecution`는 +쿠버네티스가 파드를 스케줄링한 뒤에 노드 레이블이 변경되어도 파드는 계속 해당 노드에서 실행됨을 의미한다. +{{}} -1. 어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된 - 정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다. -2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도, - 파드가 계속 스케줄되도록 한다. -3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다. - 이를 통해 어떤 파드가 함께 위치할 수 있는지와 없는지에 대한 규칙을 적용할 수 있다. +파드 스펙의 `.spec.affinity.nodeAffinity` 필드에 +노드 어피니티를 명시할 수 있다. -어피니티 기능은 "노드 어피니티" 와 "파드 간 어피니티/안티-어피니티" 두 종류의 어피니티로 구성된다. -노드 어피니티는 기존 `nodeSelector` 와 비슷하지만(그러나 위에서 나열된 첫째와 두 번째 이점이 있다.), -파드 간 어피니티/안티-어피니티는 위에서 나열된 세번째 항목에 설명된 대로 -노드 레이블이 아닌 파드 레이블에 대해 제한되고 위에서 나열된 첫 번째와 두 번째 속성을 가진다. - -### 노드 어피니티 - -노드 어피니티는 개념적으로 `nodeSelector` 와 비슷하다 -- 이는 노드의 레이블을 기반으로 파드를 -스케줄할 수 있는 노드를 제한할 수 있다. - -여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는 -두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시* -규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고, -후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서 -이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다. -이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의 -레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서 -동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는 -점을 제외하고는 `requiredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingRequiredDuringExecution` 를 제공할 계획이다. - -따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이 -될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고 -하지만, 불가능하다면 다른 곳에서 일부를 실행하도록 허용"이 있을 것이다. - -노드 어피니티는 PodSpec의 `affinity` 필드의 `nodeAffinity` 필드에서 지정된다. - -여기에 노드 어피니티를 사용하는 파드 예시가 있다. +예를 들어, 다음과 같은 파드 스펙이 있다고 하자. {{< codenew file="pods/pod-with-node-affinity.yaml" >}} -이 노드 어피니티 규칙은 키가 `kubernetes.io/e2e-az-name` 이고 값이 `e2e-az1` 또는 `e2e-az2` 인 -레이블이 있는 노드에만 파드를 배치할 수 있다고 말한다. 또한, 이 기준을 충족하는 노드들 -중에서 키가 `another-node-label-key` 이고 값이 `another-node-label-value` 인 레이블이 있는 노드를 -선호하도록 한다. +이 예시에서는 다음의 규칙이 적용된다. -예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. -`NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나, -특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. + * 노드는 키가 `kubernetes.io/os`이고 값이 `linux`인 레이블을 + 갖고 *있어야 한다* . + * 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을 + 갖고 있는 노드를 *선호한다* . -`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄되기 위해서는 -*둘 다* 반드시 만족해야 한다. +`operator` 필드를 사용하여 +쿠버네티스가 규칙을 해석할 때 사용할 논리 연산자를 지정할 수 있다. +`In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` 및 `Lt` 연산자를 사용할 수 있다. -`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, `nodeSelectorTerms` 중 **하나라도** 만족시키는 노드에 파드가 스케줄된다. +`NotIn` 및 `DoesNotExist` 연산자를 사용하여 노드 안티-어피니티 규칙을 정의할 수 있다. +또는, 특정 노드에서 파드를 쫓아내는 +[노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. -`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에만 스케줄된다. +{{}} +`nodeSelector`와 `nodeAffinity`를 모두 사용하는 경우, +파드가 노드에 스케줄링되려면 두 조건 *모두* 만족되어야 한다. -파드가 스케줄된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다. +`nodeAffinity`에 연결된 `nodeSelectorTerms`를 여러 개 명시한 경우, +명시된 `nodeSelectorTerms` 중 하나를 만족하는 노드에도 +파드가 스케줄링될 수 있다. -`preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다. +단일 `nodeSelectorTerms`와 연결된 `matchExpressions`를 여러 개 명시한 경우, +모든 `matchExpressions`를 만족하는 노드에만 +파드가 스케줄링될 수 있다. +{{}} -#### 스케줄링 프로파일당 노드 어피니티 +[노드 어피니티를 사용해 노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)에서 +더 많은 정보를 확인한다. + +#### 노드 어피니티 가중치(weight) {#node-affinity-weight} + +각 `preferredDuringSchedulingIgnoredDuringExecution` 어피니티 타입 인스턴스에 대해 +1-100 범위의 `weight`를 명시할 수 있다. +스케줄러가 다른 모든 파드 스케줄링 요구 사항을 만족하는 노드를 찾으면, +스케줄러는 노드가 만족한 모든 선호하는(preferred) 규칙에 대해 +합계 계산을 위한 `weight` 값을 각각 추가한다. + +최종 합계는 해당 노드에 대한 다른 우선 순위 함수 점수에 더해진다. +스케줄러가 파드에 대한 스케줄링 판단을 할 때, +총 점수가 가장 높은 노드가 우선 순위를 갖는다. + +예를 들어, 다음과 같은 파드 스펙이 있다고 하자. + +{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}} + +`requiredDuringSchedulingIgnoredDuringExecution` 규칙을 만족하는 노드가 2개 있고, +하나에는 `label-1:key-1` 레이블이 있고 다른 하나에는 `label-2:key-2` 레이블이 있으면, +스케줄러는 각 노드의 `weight`를 확인한 뒤 +해당 노드에 대한 다른 점수에 가중치를 더하고, +최종 점수가 가장 높은 노드에 해당 파드를 스케줄링한다. + +{{}} +이 예시에서 쿠버네티스가 정상적으로 파드를 스케줄링하려면, +보유하고 있는 노드에 `kubernetes.io/os=linux` 레이블이 있어야 한다. +{{}} + +#### 스케줄링 프로파일당 노드 어피니티 {#node-affinity-per-scheduling-profile} {{< feature-state for_k8s_version="v1.20" state="beta" >}} 여러 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)을 구성할 때 노드 어피니티가 있는 프로파일을 연결할 수 있는데, 이는 프로파일이 특정 노드 집합에만 적용되는 경우 유용하다. -이렇게 하려면 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는 -[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 인수에 `addedAffinity`를 추가한다. 예를 들면 +이렇게 하려면 다음과 같이 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는 +[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 `args` 필드에 `addedAffinity`를 추가한다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: @@ -188,29 +211,41 @@ profiles: `addedAffinity`는 `.spec.schedulerName`을 `foo-scheduler`로 설정하는 모든 파드에 적용되며 PodSpec에 지정된 NodeAffinity도 적용된다. -즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 파드의 `.spec.NodeAffinity`를 충족해야 한다. +즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 +파드의 `.spec.NodeAffinity`를 충족해야 한다. -`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의 -스케줄러 이름과 명확한 상관 관계가 있는 노드 레이블을 사용하는 것이 좋다. +`addedAffinity`는 엔드 유저에게 표시되지 않으므로, +예상치 못한 동작이 일어날 수 있다. +스케줄러 프로파일 이름과 명확한 상관 관계가 있는 노드 레이블을 사용한다. {{< note >}} -[데몬셋용 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 -스케줄링 프로파일을 인식하지 못한다. -따라서 `addedAffinity`없이 `default-scheduler`와 같은 스케줄러 프로파일을 유지하는 것이 좋다. 그런 다음 데몬셋의 파드 템플릿이 스케줄러 이름을 사용해야 한다. -그렇지 않으면, 데몬셋 컨트롤러에 의해 생성된 일부 파드가 스케줄되지 않은 상태로 유지될 수 있다. +[데몬셋 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 +스케줄링 프로파일을 지원하지 않는다. +데몬셋 컨트롤러가 파드를 생성할 때, 기본 쿠버네티스 스케줄러는 해당 파드를 배치하고 +데몬셋 컨트롤러의 모든 `nodeAffinity` 규칙을 준수한다. {{< /note >}} -### 파드간 어피니티와 안티-어피니티 +### 파드간 어피니티와 안티-어피니티 {#inter-pod-affinity-and-anti-affinity} -파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, *노드에서 이미 실행 중인 파드 레이블을 기반으로* -파드가 스케줄될 수 있는 노드를 제한할 수 있다. 규칙은 "X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우 -이 파드는 X에서 실행해야 한다(또는 안티-어피니티가 없는 경우에는 동작하면 안된다)"는 형태이다. Y는 -선택적으로 연관된 네임스페이스 목록을 가진 LabelSelector로 표현된다. 노드와는 다르게 파드는 네임스페이스이기에 -(그리고 따라서 파드의 레이블은 암암리에 네임스페이스이다) 파드 레이블위의 레이블 셀렉터는 반드시 -셀렉터가 적용될 네임스페이스를 지정해야만 한다. 개념적으로 X는 노드, 랙, -클라우드 공급자 영역, 클라우드 공급자 지역 등과 같은 토폴로지 도메인이다. 시스템이 이런 토폴로지 -도메인을 나타내는 데 사용하는 노드 레이블 키인 `topologyKey` 를 사용하여 이를 표현한다. -예: [넘어가기 전에: 빌트인 노드 레이블](#built-in-node-labels) 섹션 위에 나열된 레이블 키를 본다. +파드간 어피니티와 안티-어피니티를 사용하여, +노드 레이블 대신, 각 노드에 이미 실행 중인 다른 **파드** 의 레이블을 기반으로 +파드가 스케줄링될 노드를 제한할 수 있다. + +파드간 어피니티와 안티-어피니티 규칙은 +"X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우 이 파드는 X에서 실행해야 한다(또는 +안티-어피니티의 경우에는 "실행하면 안 된다")"의 형태이며, +여기서 X는 노드, 랙, 클라우드 제공자 존 또는 리전 등이며 +Y는 쿠버네티스가 충족할 규칙이다. + +이러한 규칙(Y)은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 형태로 작성하며, +연관된 네임스페이스 목록을 선택적으로 명시할 수도 있다. +쿠버네티스에서 파드는 네임스페이스에 속하는(namespaced) 오브젝트이므로, +파드 레이블도 암묵적으로 특정 네임스페이스에 속하게 된다. +파드 레이블에 대한 모든 레이블 셀렉터는 쿠버네티스가 해당 레이블을 어떤 네임스페이스에서 탐색할지를 명시해야 한다. + +`topologyKey`를 사용하여 토폴로지 도메인(X)를 나타낼 수 있으며, +이는 시스템이 도메인을 표시하기 위해 사용하는 노드 레이블의 키이다. +이에 대한 예시는 [잘 알려진 레이블, 어노테이션, 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다. {{< note >}} 파드간 어피니티와 안티-어피니티에는 상당한 양의 프로세싱이 필요하기에 @@ -219,80 +254,100 @@ PodSpec에 지정된 NodeAffinity도 적용된다. {{< /note >}} {{< note >}} -파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 의도하지 않은 동작이 발생할 수 있다. +파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. +즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다. +일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 +의도하지 않은 동작이 발생할 수 있다. {{< /note >}} -노드 어피니티와 마찬가지로 현재 파드 어피니티와 안티-어피니티로 부르는 "엄격함" 대 "유연함"의 요구사항을 나타내는 `requiredDuringSchedulingIgnoredDuringExecution` 와 -`preferredDuringSchedulingIgnoredDuringExecution` 두 가지 종류가 있다. -앞의 노드 어피니티 섹션의 설명을 본다. -`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는 -"서로 많은 통신을 하기 때문에 서비스 A와 서비스 B를 같은 영역에 함께 위치시키는 것"이고, -`preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티의 예시는 "서비스를 여러 영역에 걸쳐서 분배하는 것"이다 -(엄격한 요구사항은 영역보다 파드가 더 많을 수 있기 때문에 엄격한 요구사항은 의미가 없다). +#### 파드간 어피니티 및 안티-어피니티 종류 {#types-of-inter-pod-affinity-and-anti-affinity} -파드간 어피니티는 PodSpec에서 `affinity` 필드 중 `podAffinity` 필드로 지정한다. -그리고 파드간 안티-어피니티는 PodSpec에서 `affinity` 필드 중 `podAntiAffinity` 필드로 지정한다. +노드 어피니티와 마찬가지로 +파드 어피니티 및 안티-어피니티에는 다음의 2 종류가 있다. -#### 파드 어피니티를 사용하는 파드의 예시 + * `requiredDuringSchedulingIgnoredDuringExecution` + * `preferredDuringSchedulingIgnoredDuringExecution` + +예를 들어, `requiredDuringSchedulingIgnoredDuringExecution` 어피니티를 사용하여 +서로 통신을 많이 하는 두 서비스의 파드를 +동일 클라우드 제공자 존에 배치하도록 스케줄러에게 지시할 수 있다. +비슷하게, `preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티를 사용하여 +서비스의 파드를 +여러 클라우드 제공자 존에 퍼뜨릴 수 있다. + +파드간 어피니티를 사용하려면, 파드 스펙에 `affinity.podAffinity` 필드를 사용한다. +파드간 안티-어피니티를 사용하려면, +파드 스펙에 `affinity.podAntiAffinity` 필드를 사용한다. + +#### 파드 어피니티 예시 {#an-example-of-a-pod-that-uses-pod-affinity} + +다음과 같은 파드 스펙을 가정한다. {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} -이 파드의 어피니티는 하나의 파드 어피니티 규칙과 하나의 파드 안티-어피니티 규칙을 정의한다. -이 예시에서 `podAffinity` 는 `requiredDuringSchedulingIgnoredDuringExecution` 이고 `podAntiAffinity` 는 -`preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값 -"S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다. -(보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키 -`topology.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, -노드 N이 키 `topology.kubernetes.io/zone` 와 -일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) -파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와 -동일한 영역의 노드에 스케줄되지 않는다. -[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해 -`requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의 -파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다. +이 예시는 하나의 파드 어피니티 규칙과 +하나의 파드 안티-어피니티 규칙을 정의한다. +파드 어피니티 규칙은 "하드" `requiredDuringSchedulingIgnoredDuringExecution`을, +안티-어피니티 규칙은 "소프트" `preferredDuringSchedulingIgnoredDuringExecution`을 사용한다. -파드 어피니티와 안티-어피니티의 적합한 연산자는 `In`, `NotIn`, `Exists`, `DoesNotExist` 이다. +위의 어피니티 규칙은 `security=S1` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에만 +파드를 스케줄링하도록 스케줄러에 지시한다. +더 정확히 말하면, 만약 `security=S1` 파드 레이블이 있는 하나 이상의 기존 파드를 실행하고 있는 노드가 +`zone=V`에 하나 이상 존재한다면, +스케줄러는 파드를 `topology.kubernetes.io/zone=V` 레이블이 있는 노드에 배치해야 한다. -원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다. -하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다. +위의 안티-어피니티 규칙은 `security=S2` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에는 +가급적 파드를 스케줄링하지 않도록 스케줄러에 지시한다. +더 정확히 말하면, 만약 `security=S2` 파드 레이블이 있는 파드가 실행되고 있는 `zone=R`에 +다른 노드도 존재한다면, +스케줄러는 `topology.kubernetes.io/zone=R` 레이블이 있는 노드에는 가급적 해당 파드를 스케줄링하지 않야아 한다. -1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 -`topologyKey` 의 빈 값을 허용하지 않는다. -2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 -`topologyKey` 의 빈 값을 허용하지 않는다. -3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 이를 비활성화해야 한다. -4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. +[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에서 +파드 어피니티와 안티-어피니티에 대한 +많은 예시를 볼 수 있다. -`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 -선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다). -생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다. +파드 어피니티와 안티-어피니티의 `operator` 필드에 +`In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다. -파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와 -연관된 `matchExpressions` 가 모두 충족되어야 한다. +원칙적으로, `topologyKey` 에는 성능과 보안상의 이유로 다음의 예외를 제외하면 +어느 레이블 키도 사용할 수 있다. -#### 네임스페이스 셀렉터 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +* 파드 어피니티 및 안티-어피니티에 대해, 빈 `topologyKey` 필드는 + `requiredDuringSchedulingIgnoredDuringExecution` 및 `preferredDuringSchedulingIgnoredDuringExecution` 내에 허용되지 않는다. +* `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해, + `LimitPodHardAntiAffinityTopology` 어드미션 컨트롤러는 + `topologyKey`를 `kubernetes.io/hostname`으로 제한한다. + 커스텀 토폴로지를 허용하고 싶다면 어드미션 컨트롤러를 수정하거나 비활성화할 수 있다. -사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. -어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다. -빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과 -null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다. +`labelSelector`와 `topologyKey`에 더하여 선택적으로, +`labelSelector`가 비교해야 하는 네임스페이스의 목록을 +`labelSelector` 및 `topologyKey` 필드와 동일한 계위의 `namespaces` 필드에 명시할 수 있다. +생략하거나 비워 두면, +해당 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스를 기본값으로 사용한다. -이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) -`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다. +#### 네임스페이스 셀렉터 {#namespace-selector} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -#### 더 실용적인 유스케이스 +네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. +`namespaceSelector` 또는 `namespaces` 필드에 의해 선택된 네임스페이스 모두에 적용된다. +빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, +null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 규칙이 적용된 파드의 네임스페이스에 매치된다. -파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 -상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. 워크로드 집합이 동일한 노드와 같이 +#### 더 실제적인 유스케이스 {#more-practical-use-cases} + +파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 +상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. +이러한 규칙을 사용하여, 워크로드 집합이 예를 들면 '동일한 노드'와 같이 동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다. -##### 항상 같은 노드에 위치시키기 +redis와 같은 인-메모리 캐시를 사용하는 웹 애플리케이션을 실행하는 세 개의 노드로 구성된 클러스터를 가정한다. +이 때 웹 서버를 가능한 한 캐시와 같은 위치에서 실행되도록 하기 위해 +파드간 어피니티/안티-어피니티를 사용할 수 있다. -세 개의 노드가 있는 클러스터에서 웹 애플리케이션에는 redis와 같은 인-메모리 캐시가 있다. 웹 서버가 가능한 캐시와 함께 위치하기를 원한다. - -다음은 세 개의 레플리카와 셀렉터 레이블이 `app=store` 가 있는 간단한 redis 디플로이먼트의 yaml 스니펫이다. 디플로이먼트에는 스케줄러가 단일 노드에서 레플리카를 함께 배치하지 않도록 `PodAntiAffinity` 가 구성되어 있다. +다음의 redis 캐시 디플로이먼트 예시에서, 레플리카는 `app=store` 레이블을 갖는다. +`podAntiAffinity` 규칙은 스케줄러로 하여금 +`app=store` 레이블이 있는 레플리카를 한 노드에 여러 개 배치하지 못하도록 한다. +이렇게 하여 캐시 파드를 각 노드에 분산하여 생성한다. ```yaml apiVersion: apps/v1 @@ -324,7 +379,10 @@ spec: image: redis:3.2-alpine ``` -아래 yaml 스니펫의 웹서버 디플로이먼트는 `podAntiAffinity` 와 `podAffinity` 설정을 가지고 있다. 이렇게 하면 스케줄러에 모든 레플리카는 셀렉터 레이블이 `app=store` 인 파드와 함께 위치해야 한다. 또한 각 웹 서버 레플리카가 단일 노드의 같은 위치에 있지 않도록 한다. +웹 서버를 위한 다음의 디플로이먼트는 `app=web-store` 레이블을 갖는 레플리카를 생성한다. +파드 어피니티 규칙은 스케줄러로 하여금 `app=store` 레이블이 있는 파드를 실행 중인 노드에 각 레플리카를 배치하도록 한다. +파드 안티-어피니티 규칙은 스케줄러로 하여금 `app=web-store` 레이블이 있는 서버 파드를 +한 노드에 여러 개 배치하지 못하도록 한다. ```yaml apiVersion: apps/v1 @@ -365,44 +423,25 @@ spec: image: nginx:1.16-alpine ``` -만약 위의 두 디플로이먼트를 생성하면 세 개의 노드가 있는 클러스터는 다음과 같아야 한다. +위의 두 디플로이먼트를 생성하면 다음과 같은 클러스터 형상이 나타나는데, +세 노드에 각 웹 서버가 캐시와 함께 있는 형상이다. | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| | *webserver-1* | *webserver-2* | *webserver-3* | | *cache-1* | *cache-2* | *cache-3* | -여기서 볼 수 있듯이 `web-server` 의 세 레플리카들이 기대했던 것처럼 자동으로 캐시와 함께 위치하게 된다. +[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)에서 +위 예시와 동일한 기술을 사용해 +고 가용성을 위한 안티-어피니티로 구성된 스테이트풀셋의 예시를 확인한다. -``` -kubectl get pods -o wide -``` -출력은 다음과 유사할 것이다. -``` -NAME READY STATUS RESTARTS AGE IP NODE -redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3 -redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1 -redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2 -web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1 -web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3 -web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 -``` +## nodeName {#nodename} -##### 절대 동일한 노드에 위치시키지 않게 하기 - -위의 예시에서 `topologyKey:"kubernetes.io/hostname"` 과 함께 `PodAntiAffinity` 규칙을 사용해서 -두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다. -같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는 -[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)을 본다. - -## nodeName - -`nodeName` 은 가장 간단한 형태의 노트 선택 제약 조건이지만, -한계로 인해 일반적으로는 사용하지 않는다. -`nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는 -파드를 무시하고 명명된 노드에서 실행 중인 kubelet이 -파드를 실행하려고 한다. 따라서 만약 PodSpec에 `nodeName` 가 -제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다. +`nodeName`은 어피니티 또는 `nodeSelector`보다 더 직접적인 형태의 노드 선택 방법이다. +`nodeName`은 파드 스펙의 필드 중 하나이다. +`nodeName` 필드가 비어 있지 않으면, 스케줄러는 파드를 무시하고, +명명된 노드의 kubelet이 해당 파드를 자기 노드에 배치하려고 시도한다. +`nodeName`은 `nodeSelector` 또는 어피니티/안티-어피니티 규칙이 무시된다. `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다. @@ -414,7 +453,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 - 클라우드 환경의 노드 이름은 항상 예측 가능하거나 안정적인 것은 아니다. -여기에 `nodeName` 필드를 사용하는 파드 설정 파일 예시가 있다. +다음은 `nodeName` 필드를 사용하는 파드 스펙 예시이다. ```yaml apiVersion: v1 @@ -428,19 +467,14 @@ spec: nodeName: kube-01 ``` -위 파드는 kube-01 노드에서 실행될 것이다. - - +위 파드는 `kube-01` 노드에서만 실행될 것이다. ## {{% heading "whatsnext" %}} - -[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다. - -[노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 -[파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는 -이러한 기능에 대한 추가 배경 정보가 있다. - -파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다. -[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 -노드 수준의 리소스 할당 결정에 참여할 수 있다. +* [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다. +* [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 + [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서를 읽어본다. +* [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)가 + 노드 수준 리소스 할당 결정에 어떻게 관여하는지 알아본다. +* [노드셀렉터(nodeSelector)](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 어떻게 사용하는지 알아본다. +* [어피니티/안티-어피니티](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)를 어떻게 사용하는지 알아본다. From fff1dcf9c1b297414b686f13f1c5b1b706957262 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 24 May 2022 18:37:50 +0900 Subject: [PATCH 053/827] [ko] Add missing example YAML file --- .../pods/pod-with-affinity-anti-affinity.yaml | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml diff --git a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml new file mode 100644 index 0000000000..a7d14b2d6f --- /dev/null +++ b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -0,0 +1,32 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-affinity-anti-affinity +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/os + operator: In + values: + - linux + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: label-1 + operator: In + values: + - key-1 + - weight: 50 + preference: + matchExpressions: + - key: label-2 + operator: In + values: + - key-2 + containers: + - name: with-node-affinity + image: k8s.gcr.io/pause:2.0 \ No newline at end of file From 85f076192eb188458a993bbb431c173d19e338d4 Mon Sep 17 00:00:00 2001 From: xing-yang Date: Wed, 25 May 2022 01:30:17 +0000 Subject: [PATCH 054/827] Add doc for CRD version removal --- .../custom-resource-definition-versioning.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index fdcc276a45..28757ffd84 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -353,6 +353,36 @@ spec: {{< /tabs >}} +### Version removal + +An API version can be removed if there is a newer API version served and stored in the API server for at least 3 Kubernetes releases. +The older API version cannot be dropped from the CRD manifest until data has been migrated to the newer API version for all clusters that served the older version of the CRD and cleared the older version from status.storedVersions. + +{{< tabs name="CustomResourceDefinition_versioning_removal" >}} +{{% tab name="apiextensions.k8s.io/v1" %}} +```yaml +apiVersion: apiextensions.k8s.io/v1 +kind: CustomResourceDefinition + name: crontabs.example.com +spec: + group: example.com + names: + plural: crontabs + singular: crontab + kind: CronTab + scope: Namespaced + versions: + - name: v1beta1 + served: false + # This indicates the v1beta1 version of the custom resource is no longer served. + # API requests to this version receive a not found error in the server response. + schema: ... + - name: v1 + served: true + storage: true + schema: ... +``` + ## Webhook conversion {{< feature-state state="stable" for_k8s_version="v1.16" >}} From 39afd8538ddb7351c7390e5f796be8d4b2960d1f Mon Sep 17 00:00:00 2001 From: Jim Bugwadia Date: Tue, 24 May 2022 22:27:00 -0700 Subject: [PATCH 055/827] initial draft Signed-off-by: Jim Bugwadia --- .../concepts/security/controlling-access.md | 1 + .../docs/concepts/security/multi-tenancy.md | 235 ++++++++++++++++++ .../concepts/security/rbac-good-practices.md | 1 + .../concepts/security/windows-security.md | 2 +- static/images/docs/multi-tenancy.png | Bin 0 -> 34460 bytes 5 files changed, 238 insertions(+), 1 deletion(-) create mode 100755 content/en/docs/concepts/security/multi-tenancy.md create mode 100755 static/images/docs/multi-tenancy.png diff --git a/content/en/docs/concepts/security/controlling-access.md b/content/en/docs/concepts/security/controlling-access.md index e7ba78e1c4..04b13a82c5 100644 --- a/content/en/docs/concepts/security/controlling-access.md +++ b/content/en/docs/concepts/security/controlling-access.md @@ -4,6 +4,7 @@ reviewers: - lavalamp title: Controlling Access to the Kubernetes API content_type: concept +weight: 50 --- diff --git a/content/en/docs/concepts/security/multi-tenancy.md b/content/en/docs/concepts/security/multi-tenancy.md new file mode 100755 index 0000000000..f26d9d6354 --- /dev/null +++ b/content/en/docs/concepts/security/multi-tenancy.md @@ -0,0 +1,235 @@ +--- +title: Multi-tenancy +content_type: concept +weight: 70 +--- + + + +This page provides an overview of available configuration options and best practices for cluster multi-tenancy. + + + +Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing noisy neighbors. + +Clusters can be shared in many ways. In some cases, different applications may run in the same cluster. In other cases, multiple instances of the same application may run in the same cluster, one for each end user. All these types of sharing are frequently described using the umbrella term "multi-tenancy." + +While Kubernetes does not have first-class concepts of end users or tenants, it provides several features to help manage different tenancy requirements. These are discussed below. + +## Use Cases + +The first step to determining how to share your cluster is to understand your own use case, so you can evaluate the patterns and tools available to you. In general, multi-tenancy in Kubernetes clusters falls into two broad categories, though many variations and hybrids are also possible. + +### Multiple teams + +A common form of multi-tenancy is to share a cluster between multiple teams within an organization, each of whom may operate one or more workloads. These workloads frequently need to communicate with each other, and with other workloads located on the same or different clusters. + +In this scenario, members of the teams often have direct access to Kubernetes resources via tools such as `kubectl`, or indirect access through GitOps controllers or other types of release automation tools. There is often some level of trust between members of different teams, but Kubernetes policies such as RBAC, quotas, and network policies are essential to safely and fairly share clusters. + +### Multiple customers + +The other major form of multi-tenancy frequently involves a Software-as-a-Service (SaaS) vendor running multiple instances of a workload for customers. This business model is so strongly associated with this deployment style that many people call it "SaaS tenancy." However, a better term might be "multi-customer tenancy,” since SaaS vendors may also use other deployment models, and this deployment model can also be used outside of SaaS. + +In this scenario, the customers do not have access to the cluster; Kubernetes is invisible from their perspective, and is only used by the vendor themselves to manage the workloads. Cost optimization is frequently a critical concern, and Kubernetes policies are used to ensure that the workloads are strongly isolated from each other. + +## Terminology + +### Tenants + +When discussing multi-tenancy in Kubernetes, there is no single definition for a "tenant". Rather, the definition of a tenant will vary depending on whether we are discussing multi-team or multi-customer tenancy. + +In multi-team usage, a tenant is typically a team, where each team typically deploys a small number of workloads that scales with the complexity of the service. However, the definition of "team" may itself be fuzzy, as teams may be organized into higher-level divisions or subdivided into subteams. + +By contrast, if each team deploys dedicated workloads for each new client, they are using a multi-customer model of tenancy. In this case, a "tenant" is simply a group of users who share a single workload. This may be as large as an entire company, or as small as a single team at that company. + +In many cases, the same organization may use both definitions of "tenants" in different contexts. For example, a platform team may offer shared services such as security tools and databases to multiple internal “customers”. And a SaaS vendor may also have multiple teams sharing a development cluster. Finally, hybrid architectures are also possible, such as a SaaS provider using a combination of per-customer workloads for sensitive data, combined with multi-tenant shared services. + +{{< figure src="/images/docs/multi-tenancy.png" title="A cluster showing coexisting tenancy models" class="diagram-large" >}} + + +### Isolation + +There are several ways to design and build multi-tenant solutions with Kubernetes, each with its own set of tradeoffs that impact the isolation level, implementation effort, operational complexity, and cost of service. + +A Kubernetes cluster consists of a control plane which runs Kubernetes software, and a data plane consisting of worker nodes where tenant workloads are executed as pods. Tenant isolation can be applied in both the control plane and the data plane based on organizational requirements. + +The level of isolation offered is sometimes described using terms like “hard” multi-tenancy, which implies strong isolation, and “soft” multi-tenancy, which implies weaker isolation. In particular, "hard" multi-tenancy is often used to describe cases where the tenants do not trust each other, often from security and resource sharing perspectives (e.g. guarding against attacks such as data exfiltration or DoS). Since data planes typically have much larger attack surfaces, "hard" multi-tenancy often requires extra attention to isolating the data-plane, though control plane isolation also remains critical. + +However, the terms "hard" and "soft" can often be confusing, as there is no single definition that will apply to all users. Rather, "hardness" or "softness" is better understood as a coarse spectrum, with many different techniques that can be used to maintain different types of isolation in your clusters, based on your own requirements. + +In more extreme cases, it may be easier or necessary to forgo any cluster-level sharing at all, and assign each tenant their own dedicated cluster, possibly even running on dedicated hardware if VMs are not considered an adequate security boundary. This may be easier with managed Kubernetes clusters, where the overhead of creating and operating clusters is at least somewhat taken on by a cloud provider. The benefit of stronger tenant isolation must be evaluated against the cost and complexity of managing multiple clusters. The [Multi-cluster SIG](https://github.com/kubernetes/community/blob/master/sig-multicluster/README.md) is responsible for addressing these types of use cases. + +The remainder of this page focuses on isolation techniques used for shared Kubernetes clusters. However, even if you are considering dedicated clusters, it may be valuable to review these recommendations, as it will give you the flexibility to shift to shared clusters in the future if your needs or capabilities change. + + +## Control Plane Isolation + +Control plane isolation ensures that different tenants cannot access or affect each others' Kubernetes API resources. + +### Namespaces + +In Kubernetes, a Namespace provides a mechanism for isolating groups of API resources within a single cluster. This isolation has two key dimensions: + +1. Object names within a namespace can overlap with names in other namespaces, similarly to files in folders. This allows tenants to name their resources without having to consider what other tenants are doing. + +2. Many Kubernetes security policies are scoped to namespaces. For example, RBAC and Network Policies are scoped to namespaces (by default), while objects such as Secrets and Service Accounts may only be accessed from their own namespaces. + +In a multi-tenant environment, a Namespace helps segment a tenant's workload into a logical and distinct management unit. In fact, a common practice is to isolate every workload in its own namespace, even if multiple workloads are operated by the same tenant. This ensures that each workload has its own identity and can be configured with an appropriate security policy. + +The namespace isolation model requires configuration of several other Kubernetes resources, networking plugins, and adherence to security best practices to properly isolate tenant workloads. These considerations are discussed below. + +### Access Controls + +The most important type of isolation for the control plane is authorization. If teams, or their workloads, can access or modify each others' API resources, they can change or disable all other types of policies, negating any protection those policies may offer. As a result, it is critical to ensure that each tenant has the appropriate access to only the namespaces they need, and no more. This is known as the "Principle of Least Privilege." + +Role-based access control (RBAC) is the recommended method to enforce authorization in the Kubernetes control plane, for both human users and workloads (service accounts). [Roles](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) and [role bindings](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) are Kubernetes objects that are used at a namespace level to enforce access control in your application; similar objects exist for authorizing access to cluster-level objects, though these are less useful for multi-tenant clusters. + +In a multi-team environment, RBAC must be used to restrict tenants' access to the appropriate namespaces, and ensure that cluster-wide resources can only be accessed or modified by privileged users such as cluster administrators. + +If a policy ends up granting a user more permissions than they need, this is likely a signal that the namespace containing the affected resources should be refactored into finer-grained namespaces. Namespace management tools may simplify the management of these finer-grained namespaces by applying common RBAC policies to different namespaces, while still allowing fine-grained policies where necessary. + +### Quotas + +Kubernetes workloads consume node resources, like CPU and memory. In a multi-tenant environment, [Resource Quotas](/docs/concepts/policy/resource-quotas/) are used to manage data-plane resource usage of tenant workloads. For the multiple teams use case, where tenants have access to the Kubernetes API, resource quotas can also be used to limit the number of API resources (e.g. the number of Pods or ConfigMaps) a tenant can create. + +Resource quotas are namespaced objects. By mapping tenants to namespaces, cluster admins can use quotas to ensure that a tenant cannot monopolize a cluster's resources or overwhelm its control plane. Namespace management tools simplify the administration of quotas. In addition, while Kubernetes quotas only apply within a single namespace, some namespace management tools allow groups of namespaces to share quotas, giving administrators far more flexibility with less effort than built-in quotas. + +Quotas prevent a single tenant from consuming greater than their allocated share of resources hence minimizing the “noisy neighbor” issue, where one tenant negatively impacts the performance of other tenants' workloads. + +When you apply a quota to namespace, Kubernetes requires you to also specify resource requests and limits for each container. Limits are the upper bound for the amount of resources that a container can consume. Containers that attempt to consume resources that exceed the configured limits will either be throttled or killed, based on the resource type. When resource requests are set lower than limits, each container is guaranteed the requested amount but there may still be some potential for impact across workloads. + +Quotas cannot protect against all kinds of resource sharing, such as network traffic. Node isolation (described below) may be a better solution for this problem. + +## Data Plane Isolation + +Data plane isolation ensures that pods and workloads for different tenants are sufficiently isolated. + +### Network isolation + +By default, all pods in a Kubernetes cluster are allowed to communicate with each other, and all network traffic is unencrypted. This can lead to security vulnerabilities where traffic is accidentally or maliciously sent to an unintended destination, or is intercepted by a workload on a compromised node. + +Pod-to-pod communication can be controlled using [Network Policies](/docs/concepts/services-networking/network-policies/), which restrict communication between pods using namespace labels or IP address ranges. In a multi-tenant environment where strict network isolation between tenants is required, we recommend starting with a default policy that denies communication between pods, and another rule that allows all pods to query the DNS server for name resolution. With that in place, you can begin adding more permissive rules that allow for communication within a namespace. This can be further refined as required. Note that this only applies to pods within a single control plane; pods that belong to different virtual control planes cannot talk to each other via Kubernetes networking. + +Namespace management tools may simplify the creation of default or common network policies. In addition, some of these tools allow you to enforce a consistent set of namespace labels across your cluster, ensuring that they are a trusted basis for your policies. + +More advanced network isolation may be provided by service meshes, which provide OSI Layer 7 policies based on workload identity, in addition to namespaces. These higher-level policies can make it easier to manage namespaced based multi-tenancy, especially when multiple namespaces are dedicated to a single tenant. They frequently also offer encryption using mutual TLS, protecting your data even in the presence of a compromised node, and work across dedicated or virtual clusters. However, they can be significantly more complex to manage and may not be appropriate for all users. + +### Storage Isolation + +Kubernetes offers several types of volumes that can be used as persistent storage for workloads. For security and data-isolation, [dynamic volume provisioning](/docs/concepts/storage/dynamic-provisioning/) is recommended and volume types that use node resources should be avoided. + +[StorageClasses](/docs/concepts/storage/storage-classes/) allow you to describe custom "classes" of storage offered by your cluster, based on quality-of-service levels, backup policies, or custom policies determined by the cluster administrators. + +Pods can request storage using a [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). A PersistentVolumeClaim is a namespaced resource, which enables isolating portions of the storage system and dedicating it to tenants within the shared Kubernetes cluster. However, it is important to note that a PersistentVolume is a cluster-wide resource and has a lifecycle independent of workloads and namespaces. + +A StorageClass can be configured per tenant, for stronger isolation. If a StorageClass is shared, a [reclaim policy of “Delete”](/docs/concepts/storage/storage-classes/#reclaim-policy) should be used to ensure that a PersistentVolume cannot be reused across namespaces. + +### Sandboxing + +{{% thirdparty-content %}} + +Kubernetes pods are composed of one or more containers that execute on worker nodes. Containers utilize OS-level virtualization and hence offer a weaker isolation boundary than virtual machines that utilize hardware-based virtualization. + +In a shared environment, unpatched vulnerabilities in the application and system layers can be exploited by attackers for container breakouts and remote code execution that allow access to host resources. In some applications, like a Content Management System (CMS), customers may be allowed the ability to upload and execute untrusted scripts or code. In either case, mechanisms to further isolate and protect workloads using strong isolation are desirable. + +Sandboxing provides a way to isolate workloads running in a shared cluster. It typically involves running each pod in a separate execution environment such as a virtual machine or a userspace kernel. Sandboxing is often recommended when you are running untrusted code, where workloads are assumed to be malicious. Part of the reason this type of isolation is necessary is because containers are processes running on a shared kernel; they mount file systems like /sys and /proc from the underlying host, making them less secure than an application that runs on a virtual machine which has its own kernel. While controls such as seccomp, AppArmor, and SELinux can be used to strengthen the security of containers, it is hard to apply a universal set of rules to all workloads running in a shared cluster. Running workloads in a sandbox environment helps to insulate the host from container escapes, where an attacker exploits a vulnerability to gain access to the host system and all the processes/files running on that host. + +Virtual machines and userspace kernels are 2 popular approaches to sandboxing. [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code. [gVisor](https://gvisor.dev/) offers similar isolation, but rather than isolating containers with hardware virtualization, it intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host. + +### Node Isolation + +Node isolation is another technique that you can use to isolate tenant workloads from each other. With node isolation, a set of nodes is dedicated to running pods from a particular tenant and co-mingling of tenant pods is prohibited. This configuration reduces the noisy tenant issue, in that all pods running on a node will be from a particular tenant. The risk of information disclosure is slightly lower with node isolation because an attacker that manages to escape from a container will only have access to the containers and volumes mounted to that node. + +Although workloads from different tenants are running on different nodes, it is important to be aware that the kubelet and (unless using virtual control planes) the API service are still shared services. A skilled attacker could use the permissions assigned to the kubelet or other pods running on the node to move laterally within the cluster and gain access to tenant workloads running on other nodes. If this is a major concern, consider implementing compensating controls such as seccomp, AppArmor or SELinux or explore using sandboxing or creating separate clusters for each tenant. + +Node isolation is a little easier to reason about from a billing standpoint than sandboxing since you can charge back per node rather than per pod. It also has fewer compatibility and performance issues and may be easier to implement than sandboxing. For example, nodes for each tenant can be configured with taints so that only pods with the corresponding toleration can run on them. A mutating webhook could then be used to automatically add tolerations and node affinities to pods deployed into tenant namespaces so that they run on a specific set of nodes designated for that tenant. + +## Additional Considerations + +This section discusses other Kubernetes constructs and patterns that are relevant for multi-tenancy. + +### API Priority and Fairness + +[API priority and fairness](/docs/concepts/cluster-administration/flow-control/) is a Kubernetes feature that allows you to assign a priority to certain pods running within the cluster. When an application calls the Kubernetes API, the API server evaluates the priority assigned to pod. Calls from pods with higher priority are fulfilled before those with a lower priority. When contention is high, lower priority calls can be queued until the server is less busy or you can reject the requests. + +Using API priority and fairness will not be very common in SaaS environments unless you are allowing customers to run applications that interface with the Kubernetes API, e.g. a controller. + +### Quality-of-Service (QoS) + +When you’re running a SaaS application, you may want the ability to offer different Quality-of-Service (QoS) tiers of service to different tenants. For example, you may have freemium service that comes with fewer performance guarantees and features and a for-fee service tier with specific performance guarantees. Fortunately, there are several Kubernetes constructs that can help you accomplish this within a shared cluster, including network QoS, storage classes, and pod priority and preemption. The idea with each of these is to provide tenants with the quality of service that they paid for. Let’s start by looking at networking QoS. + +By default, all of the pods on a node share the node’s network interface. Without network QoS, a pod with 100 network flows will always consume a greater share of the node’s bandwidth than a pod with 10 flows. The Kubernetes [bandwidth plugin](https://www.cni.dev/plugins/current/meta/bandwidth/) creates an [extended resource](/docs/concepts/configuration/manage-resources-containers/#extended-resources) for networking that allows you to use Kubernetes resources constructs, i.e. requests/limits, to apply rate limits to pods by using Linux tc queues. Be aware that the plugin is considered experimental as per the [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#support-traffic-shaping) documentation and should be thoroughly tested before use in production environments. + +For storage QoS, you will likely want to create different storage classes or profiles with different performance characteristics. Each storage profile can be associated with a different tier of service that is optimized for different workloads such IO, redundancy, or throughput. Additional logic might be necessary to allow the tenant to associate the appropriate storage profile with their workload. + +Finally, there’s [pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) where you can assign priority values to pods. When scheduling pods, the scheduler will try evicting pods with lower priority when there are insufficient resources to schedule pods assigned a higher priority. If you have a use case where you’re running freemium and for-fee services in a shared cluster you may want to give priority to your paid tenants by using this feature. + +### DNS + +Kubernetes clusters include a Domain Name System (DNS) service to provide translations from names to IP addresses, for all Services and Pods. By default, the Kubernetes DNS service allows lookups across all namespaces in the cluster. + +In multi-tenant environments where tenants can access pods and other Kubernetes resources, or where stronger isolation is required, it may be necessary to prevent pods from looking up services in other Namespaces. This can be done by configuring firewall rules for the DNS service. For example, CoreDNS, the default DNS service for Kubernetes, can leverage Kubernetes metadata to restrict queries to pods and services within a namespace as described in this example in the [CoreDNS documentation](https://github.com/coredns/policy#kubernetes-metadata-multi-tenancy-policy). + +When a "Virtual Control Plane per tenant" model is used, a DNS service must be configured per tenant or a [customized version of CoreDNS](https://github.com/kubernetes-sigs/cluster-api-provider-nested/blob/main/virtualcluster/doc/tenant-dns.md) must be configured. + +### Operators + +[Operators](/docs/concepts/extend-kubernetes/operator/) are Kubernetes controllers that manage applications. Operators can simplify the management of multiple instances of an application, like a database service, which makes them a common building block in the multi-consumer (SaaS) multi-tenancy use case. + +Operators used in a multi-tenant environment should follow a stricter set of guidelines [2]. Specifically, the Operator should: +* Support creating resources within different tenant namespaces, rather than just in the namespace in which the Operator is deployed. +* Ensure that the Pods are configured with resource requests and limits, to ensure scheduling and fairness. +* Support configuration of Pods for data-plane isolation techniques such as node isolation and sandboxing. + +## Implementations + +{{% thirdparty-content %}} + +There are two primary ways to share a Kubernetes cluster for multi-tenancy: using Namespaces (i.e. a Namespace per tenant) or by virtualizing the control plane (i.e. Virtual control plane per tenant). + +In both cases, data plane isolation, and management of additional considerations such as API Priority and Fairness, is also recommended. + +Namespace isolation is well-supported by Kubernetes, has a negligible resource cost, and provides mechanisms to allow tenants to interact appropriately, such as by allowing service-to-service communication. However, it can be difficult to configure, and doesn't apply to Kubernetes resources that can't be namespaced, such as Custom Resource Definitions, Storage Classes, and Webhooks. + +Control plane virtualization allows for isolation of non-namespaced resources at the cost of somewhat higher resource usage and more difficult cross-tenant sharing. It is a good option when namespace isolation is insufficient but dedicated clusters are undesirable, due to the high cost of maintaining them (especially on-prem) or due to their higher overhead and lack of resource sharing. However, even within a virtualized control plane, you will likely see benefits by using namespaces as well. + +The two options are discussed in more detail in the following sections: + +### Namespace per tenant + +As previously mentioned, you should consider isolating each workload in its own namespace, even if you are using dedicated clusters or virtualized control planes. This ensures that each workload only has access to its own resources, such as Config Maps and Secrets, and allows you to tailor dedicated security policies for each workload. In addition, it is a best practice to give each namespace names that are unique across your entire fleet (i.e., even if they are in separate clusters), as this gives you the flexibility to switch between dedicated and shared clusters in the future, or to use multi-cluster tooling such as service meshes. + +Conversely, there are also advantages to assigning namespaces at the tenant level, not just the workload level, since there are often policies that apply to all workloads owned by a single tenant. However, this raises its own problems. Firstly, this makes it difficult or impossible to customize policies to individual workloads, and secondly, it may be challenging to come up with a single level of "tenancy" that should be given a namespace. For example, an organization may have divisions, teams, and subteams - which should be assigned a namespace? + +To solve this, Kubernetes provides the [Hierarchical Namespace Controller (HNC)](https://github.com/kubernetes-sigs/hierarchical-namespaces), which allows you to organize your namespaces into hierarchies, and share certain policies and resources between them. It also helps you manage namespace labels, namespace lifecycles, and delegated management, and share resource quotas across related namespaces. These capabilities can be useful in both multi-team and multi-customer scenarios. + +Other open-source projects provide similar capabilities and aid in managing namespaced resources: + +**Multi-team tenancy:** +* [Capsule](https://github.com/clastix/capsule) +* [Kiosk](https://github.com/loft-sh/kiosk) + +**Multi-customer tenancy:** +* [Kubeplus](https://github.com/cloud-ark/kubeplus) + +**Policy engines:** +* [Kyverno](https://kyverno.io/) +* [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + +### Virtual control plane per tenant + +Another form of control-plane isolation is to use Kubernetes extensions to provide each tenant a virtual control-plane that enables segmentation of cluster-wide API resources but shares worker nodes. + +The virtual control plane based multi-tenancy model extends namespace-based multi-tenancy by providing each tenant with dedicated control plane components, and hence complete control over cluster-wide resources and add-on services. Worker nodes are shared across all tenants, and are managed by a Kubernetes cluster that is normally inaccessible to tenants. This cluster is often referred to as a “super-cluster” (or sometimes as a “host-cluster”). Since a tenant’s control-plane is not directly associated with underlying compute resources it is referred to as a “virtual” control plane. + +A virtual control plane typically consists of the Kubernetes API server, the controller manager, and the etcd data store. It interacts with the super cluster via a metadata synchronization controller which coordinates changes across tenant control planes and the control plane of the super--cluster. + +By using per-tenant dedicated control planes, most of the isolation problems due to sharing one API server among all tenants are solved. Examples include noisy neighbors in the control plane, uncontrollable blast radius of policy misconfigurations, and conflicts between cluster scope objects such as webhooks and CRDs. Hence, the virtual control plane model is particularly suitable for cases where each tenant requires access to a Kubernetes API server and expects the full cluster manageability. + +The improved isolation comes at the cost of running and maintaining an individual virtual control plane per tenant. In addition, per-tenant control planes do not solve isolation problems in the data plane, such as node-level noisy neighbors or security threats. These must still be addressed separately. + +The Kubernetes [Cluster API - Nested (CAPN)](https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster) project provides an implementation of virtual control planes. + +**Other implementations:** +* [vcluster](https://github.com/loft-sh/vcluster) + diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 2434b13f75..41a7e555b5 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -4,6 +4,7 @@ title: Role Based Access Control Good Practices description: > Principles and practices for good RBAC design for cluster operators. content_type: concept +weight: 60 --- diff --git a/content/en/docs/concepts/security/windows-security.md b/content/en/docs/concepts/security/windows-security.md index 1341f38c59..8d661235ca 100644 --- a/content/en/docs/concepts/security/windows-security.md +++ b/content/en/docs/concepts/security/windows-security.md @@ -6,7 +6,7 @@ reviewers: - perithompson title: Security For Windows Nodes content_type: concept -weight: 75 +weight: 40 --- diff --git a/static/images/docs/multi-tenancy.png b/static/images/docs/multi-tenancy.png new file mode 100755 index 0000000000000000000000000000000000000000..0ce341120a19047d0087c68659c46ae98bef348f GIT binary patch literal 34460 zcmc$G2UJs8_irp?2OO}03L{meNtYTGQGoyoia-Q3G*ODuAwW=+A|TQU2oa@-f)J`w zReIMTy-9BYq=lN~otvPdGxNRg{oh;bvDPdn$vth?-`;2M>w8iCJi`vQ9WWS-LHWX2 zO&DymCk(bRZ`(%j4NvV(D)?uEt>*bNus8LGM!|>8W~bFo!(jNpovSzg0H3$txu9zc zgK>{Q|82N$^v59>%u7W1?CHx+1`}OfX@V8bJ)mY)NqrRm4LqS{i8W7=5~Jt8ZpW5lb^o8R_8mUB*}zQk<%0nuSYPm6g}BoDYxa<51 zk|(w{i>lfGd@8iQRG?Vq&`_ezo2F9)|SQupB=_l{srqm`+y-nK2;=F#qx5eg<~ zNs>}-La~XXjHl638HN;XVD930+nr32f|HVa=DXO&Z59V})y2$Yr)T{o9fq3AWZPRl zGlSiqI>?x;G>Q;Va2P4mWHf(rqpdO-$;VP-VUuK8L6CoGqLO48!^|2qFLQ+p? z-QbpkWttajKE)R*8~T_y&M4O_mq6UQ&cfKRtR#kSfV;Y$Jg4c^eSR!VIaf5g)4T(J zL1EUf4bH)gj*jxxeQw`=;#!{d;{@S&^jT36F!Y(cw;B04HjvwpPua5ETS2Mhj z8*j!4&B(AeqgdfFt#eTc7kX-W9oroQ%oRdn2|df7G|m^UKyqP?T$=KX(c|#ru`nhZ??8~=JQRe5w&y6Bda*bM& z=kdD=A2bdbjk<3ZA!my#QwjU~%4`a`u&jG95Cv{xPTL@~mYFOxbhVj|91QtFf9KZDu%-HvEs z0-@6ZF^{Flv#h|WCDA;q3yxZ$)MX9|i}@3?2@QE!H!&K`Tg~I6-EVxg=4*EsIIn`t z13L`Te;0R{G0d!Z_59}r;!bFTpCU^dF`p3#ihWA)QXDRPi!)YW&|;%4pjFqLvSw*k ztF&r=qnFWWT`3`iRm*FcRJ0omg9S*-k@we?=5hS7+F4RT;N=QQc&c_?z2k9$lv{?_ zQbIlk)$P|*sT?bLs3vluG)3*)vR9<^${A>^_|UgGLva?d;4vKnCxfV{Zgtz{A;4?_ zYEWvj24=FiXZ4c?E{eS-Z52@cLo!Ln#nB`zsjh+(Ia~j8`H1?`ykbQj>m3Oejg>ud zDpI-`5murz$(63WLj?az?YLWk2~r`UCFEtYwTkC1nxtK~X4If203nqJLR#C!X)S~8 zS<3C9yfa)5wN%LrLWK7Pyoi_0O4G=e;;Bm^y1KxREahTI95_8QF_GKhRyH$id_0%2 zE!)63o+*1LQ3=?{Af_qjrPmm;wN76zfoW@En~$5@s|n*{U3N7#VzL*bE-ERD@oV(D z_u|N=%Vx|b)-&g2361G}TQlTW2}$mbF9Y17i^NF82x=u`uXjE1ngJJ>-Gdh}ncooKFfbRYr;xdW7L+3W4M7&#YL2t$_6ntYZwri zk3~#z385!|RqlBO4eii1$CpmE2~$6hM(0;)P{ao|pRo?-NisfM!EH2yG^Sbo_uYqL zDX&dXLtske<1f)~R_mC^Sp~YrtNpG9goWz+JVqH(9f6qDhMDJDSB6^%UiBZw(3pp{ zt=)MzbZA#p?anL|dc;9`g|-nIr^Q%yhPN)_l+cwzCK*TQCn-UJ6 zW1+A2U;|(t%fJACm07(PdFGwU|F;LM#PHO9>WUcblmz7zBJNs3rNw60m-E0ExAZcV zwg?FKtavC<&Dft7)kQ=Yx-ZS`O?b$e`6uim2XMXDyy3eIGyNM%+2w3?1j~6XLmB8N zV^n>uWW17Q0fX%sgl3V)MqYLM8e2de#OfsFX>G|%du`Fj?YEys2FBaJKHM*c$3H|^ zh$)$J!Ja7~10XW(SiQFx1-`8K?aPx_A0I0@V&t^+q0o%6tt8I%D|Tz_nS#~7lJldr z7rnO+=H}&X_i5=Amn93ecGAXd zuDz?;MSQn1^iJj#!ORk)J#`sTTl(1Kt8`HkIGIDS7C9rf-_va1@X;x|;b%#&6bIEx zUXB$}>dl{4-wz>5-;2(hlQSy{r|2KPrSL@i@Jy8vE_R3<;b~L3LjfgN4n&r6EGWv z1r7Ku4c+hLPZ@d6&AF&Mb$WCj+o_(hu-T>IeYJnf^Ze?f$BIGxUFhBw)!L?uH|otk z74BbKN;OY)Wsp&%gGSXaxifK6c2i0Va(N5S^QQrUN8NNdLY(Flo;c#h&?NY`5n(}c zM|`K<$V9h!On66*a1w^UKPNtkFR9n0_Q$gI*C%g()}J@1lpR#}o2|3{msL;yhgGK( zNIl|mv#_)PmxUfnJApzof|g4@6LHpRS}R9;8L2gT8m(ajEjg=^LES84c7mEc^5)#r zFb?8d+(6AN&(N)xCx*q=$f>kYz|)mLw()*x`DYu2{~!#ew6y8&n>mG)aU*Kn$R_mE zCfD2yGisqc8c7PLOmc}nD0 ziTG?pt*AQRJS?39Vpk#4xLZREjfmOlbj2sOvW@$+ssPA zm<-4GeZ%?xwrBOC%dNuzdEX8(jh_Ibu8lD zA~$bq~tl`H0HcIbddm^?Cl2S8e#|$ey^Uj79%JxJY;Gn#W&c~HM(DI zi{V|3H5GqHQ*p&hz*Bvtuc;t8eR7qneA>f(wIx+XekEkXZO6u`WHa^Dt$L*J*vX2S z3`-xu@T)po<}wN%b;MSrR*W@3+y_QJ290NtMjMm5!iKG?vxvFV_w+%oC^q~m?)mp_zdj*&;^|m_euoJ!!jr` z$J7|5RQUkrQ5Tf%MSg;X!8$laEbDF=qo_llaT5WEZLrou+i$lrVYkE51(_S01w=)X z4IcwEA&L0NMp8802($1j&62n+$g;8(xB4n%x%%%*42njK8>0qAYn1=?n+7;``VHph zA6uVb0ra}#euH6i4-REn*0>$nJd2cYR91+_9%TYqLD*({*-b;DiDgL`@ye5`r zTZ$-sQ{-~)9=B1|j1c)nN-hR|_yL?!KAfGt$)hZ1Mh@b>C##0f3uaI2W|=UPRpWg4nR7EyFMTKs|4 z5k@9!2+v>Zb&QQZ0yqrBTKf#|=A0Uv%#zDR$M$_n_|UC07 z6AZuuse_o4zSkI4SZ;>WCM{ik+s*}Ms4RW-Wc$5|s8Cm7W%u%W*sO^+Ypb=NyCwAE1svhs(i{{)V`hb&CGrDJc}TIW(#_GNT++XdnbXt zgNIIgja*mo)5yPJs zR)|m@Al42h#hGIx{1e7?iTA*)D&J?-sTWHR~w zZJa@gilppRzg2~P6x;Mlb9#I6Zd`+Wt=D)UNpr$8lEaLdYlK>IST^Pd;uGRYWPztUelT+K|P1q zLjLf*vJWh?UsT>Vn;(sB$Y7D3mkW1F(1hFP>Il-cy!B0{Y9zj?H_Q309mXa%F3|od z2#Xuj#X?hCIepDeb1+eP!7_$knDnl+`&xpfVpZ%3D=xEHU;5 zIeM(ES3SEz)V@%;LFI8YehWmC`8Lr;I>mvSC}v=P@}_qDRv8mrM}up^;WL1pOSwAQP^x zP$8q>c2;Q)X=I2)uDyEBP{OFTtN3T-v7=KnH-0V*(i-fXquOGCg7O{iMDc4buSoNY zL`Hr-z#mSQkmW(f#yodk(gJ+x3g3KK)r0pAgApRWQy@XXk<-Q;=AhAb@BW-hbV5y} zTa1;cO%5ql{6ao5D3w)_Lyg!a<9@F+if)nhrY3UrsSU!JB*qaE^WD*0&*v4qVW#S+ zhClp(3R@HiDUexM`@OuOs%P?h=sm8Ysg}(RW*99&o)V+f)jqPhDbVI z)B2^U-H*6Anu~4;I>HP;8Y`Vd5{eEk>r}KMYU4T5b2%|y-~ka!9HSN%u?rbtST5ix z0|-2gm(^F#D|X1vK?vwuS-#7NnF|i{XL7QL`FZY+stOrmsQTf@3HeAaOCr*o<^VOk zlM%dLsWrkznbc4%cZpz(h*($Xln#nDB#_rML#;|RKgrvY?j1cQs)cU^yT?b*F15MV)Yh|8vb3 z!*Wsc8!gG7)p~_DT7S3B5KlO8*~@EF5}j8sUXP)%;yA>LnVLwvvC)9pU}I4RlAn@X z+$iO!Iwv|Gf!As@l3sB<$!!^efw6UP{-hh}8=lctk|iW}G3CN0i^mY<)lC{oi>+J1$Q z+Kd`TAj6e-ri5es4hZbKr$5lFhz+*phI&gwX?0UOVH2&~ww$D6~v4oqE#7d2GKeA@iO82*Nk{1GYJu)Asa><6m(zXoJ9XS)IRT{mbj zD5?qEgDhAV;ekE;4eDi9md3lk1E6bKSXR}|~+(5kG!9WKpbi{}QiIVFj>u}NkqiK+0ba?eUYNba8zig9cPXROs&^crsqP?gt zcOTZeef!3T00L(oU`;lhl)<*D{KqHO;oCFP)7v&)=i}bC2g1cD<9K)Jb@Ul5<*L-6 zeB{`8Q>T;2ym z`ul$ohC+)q*c*XbBrL!;TL1p3BM=NfcWx{Kim=wW0G+Z@@t{X}X`RsNXS;!H z?&IQ`uUQ9_kMgmf9*AQ&Wz=UH@z+HkfE@gSf|dtC4o=v8HsBVeo3FSpzDRVPF8`rEq?)o4h?x{}3U|cH0!X&(in%#0PxClAd>3MZPiPhZm z%NwtwYkc^Jome`}dc$*)o&}kVYYc>Y#TY0j70i>+4R9C5_Nk`~mFOwz!@vghVElKA ztQUJa8M1qu_@x^Az$5h`EFYdy&490L2aukc6=hY7VE;%3!Cl_Lt_R>(& zj{uS`h{)IV3a-eFq{Vs1f`EwJZuhBPRgHLTW=z5IK-Xec^xl>BJXNvT5hOf4wW!J^ z0i#k%y1sSZl%%xGk7y>o+nTnRm}!yQ{dyr`DbWVoS`e3hHKNEsHN@g}du!c@=oYNb zrSDphul}oj4rK}a3p&wiiQ_W=71Bfb!Ic*6JmoS+1Lu{jRIQXWaZqM-|niSC^mAcAbO8} zH8C!|FRf*)QC!F1qrZ^RqSf$x*Yoev^-t!;M=mS-`0O{!(FaW(A%$NK_RQ4>c5Co^ zv-gl=#8ur1)hFLf7pN~CMAm`e-AB*Uf|@hZBCml$T~TD}0Xju;x&5R$fAL~xq%m*z zP8I(Cw_WmQ(aI&Y@t2R-1b3sVjLEJ>V;3WxtWTsq{cPf|T+-q3+llaOeajmln>?!0;v)HtNJT(MR&D9bnho0FJ^0`g$$_>W6f`ERA0$WS_Pje8o|B-(+LnEQ5keu=ZN zuPd@UIHz`i8LQ@SvPYcvN~P4})bPKm5-)RGn6u9E>+EOU(TKihYR78iP!aIxHv|9r z$QxX()0*K286OByRQu`*W)?!+5M!?vOqdo5e<|lW>T7SeWcXNxU*9xjqE0G6`gLXi zx+ji#VUmL)f4dj+@hK^JJH7=LRvTWzz0=Zm=KcLL2p6y%0e?mlMKFZbzsTrh&% z|HGrbs~wbNS?MX7J|}TEAp!C;gQeqP|GJti;Q%^CW8B-=#Zt0OdKgfQO|OH zS8-W!Coyis?R8zxTlCaqG0%w?H3#q=BI~3KSmj$jE&O8aYtHU5Ed~G%MZ3nr`pQr* zny|@@SE`bFn3P2@k&ID$qq$T*UH*9yUMxZY3YltN=$qRzz-?y7%H<$y>U41T+9`m0 z(qWi(F)80f_jT3usNkY{?Jev?YPFne#nwF&cMWqC7QXJSF(%~J^rdwtZTFDy>nu_E z5`EGNlCqhqFrRYL8RGc$cPg$zcgqi+H>+dc!SA5p;ALPvY~JHi=vsg0T*MLJ;mg%q zR}#5+Cy>nl-TKBTUiP}wR<0tR6G0_9__W6IAakdhMM;NX$v0SEhA>C>IZCCS$t!2Y zpvMk+0@;QHTrTq6#8>3qOE2^J5vhK-L-PM|U2>j8dMCvc{vsGO} z?gmQU;(=w|RCSLxkfr*?Ox!zDS^9?OH)NRNbl9mZRQQ!IPh42 zyiXE_dm#btteW$&a_%n{{?k9Ky-CiRi2p#eogiEYd$RqK`ZYLqTJ4d>wk&ch`C9@X zMU-q9hNr4{#;8)IBNq3|RRNGg%V5&g;_s+dTah+JyE5<46scgTgab1imP?+W=|FuD zDh%`uXee9>bQI;e2BFDcH0)oeVxzWBU?vogi!CnAg8@O!M=Ox=|;M(-taeUp5pb^U9>;ij)d>fjF_|5*Kr=7SP)1E zGOc%*84Gc2?5WI1Lt}UrKIgh$N4kZ~t58FICXP^^d$|QsW`ZT6rwzh6Y93+6aYdOd zep?>a9%Mk@8&%CYRF#t$(B&`01#{*Q3tu4$Nd`CUuu4Et4XW^GP4o9V=Bdf5G2 zRrtB;RQZL+HDBCVnN|zN)Q^a2nyO^+K|1skPDpsfJXsgzKn`J?kI7Pv&4u__>T$|x zy{SHyyTP009!cE?kjcuC>9Yahgcz6dx7zbI!6&JcM^vI^*b=3z0f32T^(@d|r*msJ z9)4x|V-Y~P04ncHkE@uhyyC)9kt&*brIe0aAVG^h$Gbf|!D+>+d~n{H@~uMCu>H&D z6Vv==qpxGZ#I3XbMbWgN&t_fZjLf75=T167&}B*}OWIXHB=Nb{!}HdKoxI#8l!^BkG zEpQ)$IeVJg;ES=8ZoN>E;`{bNpHJW=+?oKO%!;2HqQ#)=Z;e3c2H7-#%Hsj0SOfcm zI&{Kkfc0qpJctoHo@$3x%aQ64A4=(a;lIR*k$W-TO)i0(3)UBfI3#~QQP=|DS5Wv| z*VA?O^T$;X+0ateC!lw(!nKmNFZG=5-J)GOyJw8)hOK-P4~w{XqodXdDdm z!*`*XFbi?FRSc`MovtIayR$VX5Ad$CVqjO$Y^#`?9-KSmz?@Z7d$(G3X@SX*(E}!H z%JHhomXqDY&kzz3JGW$+3+Vbt9$ZcSc8RpMJs{+m+L)rJ)c7GBWdmT*}!(-~Plfp-gjEUeeGvxN6L!p7so)lBA#rT0Esyy5eeUL!pWO;qWAWbey;#i0;*6C<2s$qdL zekEy2mU`f7JZraTQ9w+5fS)O9!HS|gCjRGG_P2=_{?0Fg7@hR;ridVBDkY$YgayqofDji%@oOTeDffw~5QAcxn~o5CuH$fH`>9+%<3E}|YsOr_5yIWC zb!g~~_7$E?mf{k_JEOZ1Gz~?Ab z&4cf7{V$NvS&WGBgS=XS0d^8?$}}E+=I!K^!ggy(%8R>}2gTUT^#-mb(HT74&nH0w=I z8D;!6^!QgY-z6L8{RY8-5dEFLAX@=pjmb5-|4+ADeCeMuNk=4I0*mH7BPaucv#T$p zjBlf99q7izARW~O#ONaBW3s1}p$RbP}$&Rek zOoKqWc{;co0jVY)Q$hw0&GSH%3Zqp%l$nIDd4>J!BXmHk!8pqoG;DVz@EEe8l(?#q zX8g<*V5@|k2pMI8mEh3YU~%&vf0|qY*{4TIJ0Vc;9g+eu12)=!F=?V>rPW|98&%5e z->r56V!ot;q{w6!hA2T&ii%Zoqh}K7w&7lA6twTpJnGZjx8qfgA$4ABa@RY5f_VV#enpcGc*)ebOU) zpdiiqJ(c$8(G`$rjJhkylDU~UJwD}hP#Cz&?oaugIU!eZ1qX5DOq3zg(cF~XZG3A^ zlay}SoQ7{Jd!Ib(3Mcv6Qwj9s2mYc_fsWLLF*oy~WK&*A>pR5xM6PcjzcNM6WEIOp z?9~Ey_0lvm^)og5QYRbu3f3ir06FY9n5v(lYY%6)*yz4-{s8jZ@NH#V|7h%+z+vXj z9g=_48ULbU2!WaqOQnP8-9-(05W6x9PY=9jNh(`fT#5vc#=n zf@U}9?&U{e$C*p`TQ!PEvDNL}DhncA!CPPF4m%}F6;-j*NI)CcY^s!xZsbhDi=&n06~a+^hN^{_1fz z$4Lu(Il;|8+0&@+YCYj}s5x&$SfjCI4is(Z(MgfqMic5baGZJx6SzEX2wz~Qrr z)(;J%8*h5y6IA)}<96xMqa=`{zg_-G%mqShkEAqQRNF;Eq>UxpdR-eM{W*J1=IF_A zN8it8og!|P5Eea|xDX5$I2ZpST%ih3v&BE&c5t#=BR33Q1e=&+ij7+ zGCnd>ydw;x=Xg7!=^3DfB91GS30o@W45C=|>ode_d!&h!y-#?{p!GN}Ug%lk!#00M@1RY@*orUyQjjM=fl^WI9@NwHG_Ph#yAD5&5gB za;i@VKz2kOBE7KRtzsSB@BO?2Q!3K}Iadj;*suAc)$tVz2;NUCd|%LFyCd4{J|G0T zd8?^QrGAm}C%fRme_E$inKz6C<4eSAf2Hg{9DI6nkJ{C~O^---gpm^)xBwxGxQai+PbOmN0w-M^ORtJN2_xCTVV7qcQ1Wj;R*>E9AZ$H zp_t>p2wB3@RMRp&hsuJ*M_Xx`+)xNP{X3n!ZJ5#b7XptZmJzn2`=%U%#NW#(P)7os z-fAG1?^?pm6Z{tX;=2*mrNEh3tSpes@ha3!UWB5oWY7LENw(3~-we!+q+Y0|#hnh( z#LOM{fs&%YJT(h=DgAouby@CVrD8{S>!!THU2j%u)IUaFLFbzz%Xg_qX}`-XG_||; z>sWfcwhOlZ2<@&s?xoWXaIg04sg<66v%k>pfA+OM?jDaG*R})~V$}ehJ^C&$z>EI4 z_}sJiHFOa+2=J!TcSEF+i)|gI;^3*gLYZH#^0I7%Nv>s9Y4-KtMMiAvmG5l(j*OOF4u%)Fu{C4LALbY(r*-5-6HcQedlEp7X} z@7QJ<)cFAyLADyIUHcDDtfS8Vn}W!Hynlx(F@G|2EiXVXQv1F)dT0&R5P&?v54oeq zu4{-ctVVz@X!~z>`~Ohl2niB}jMHYpM*bp5^mW$*s{j5<-n<2>c0I_`0P0CWbtmnL z)ng*ajO}OTC8$CryH6UrmMKFx9V$wNYE;+CY02~(VNgl275XKDphvHV{U6rFB5z|4 zKt;fyBzB%Z;@veq7XAobTGQh)FreV;AB~$Gmb|25$_h{`P>%|&?IHiyTEQ+*NbvVe z5?s@Rzn1}^cme#~TC3-Ehbki0pCscsqL#VtB}cIGxzX733kG%#FVMny!=HbY>_Y|m z^m29}cSL)c&F3UBO5rBkA)uI_ijH7rUiL7SIPyIIAVHbA?Ox;1ZX}qdtP&g ziMP_^AF%hA!I4hj;K727{ff;ZU|M!$snzy-ilA zqx@)(V#le)Yt|a&+QVU^vr{Pu;x`?4+Xww0QaX({IU-G~)r#)QWkwgqEC4;ATjW+4u~l)KV7r_kIb-x%yA9-(I*N{=epI#&Ba`1_}ml^la zr26ogH)UG1MzW`af${J90`nbl9V_hjX#GeHrR(~UlAb#6;jq`<#CPX78R`A_^}JhQ zp}Gv(H_L{Co_=L%lb>Z;<4v9jo-=-G(`nxKsBwxx+zi3vH3 z$xUyy%h2s~`{oYrfc&2gHLi{r?z*r^v8=HEO;gyUk#6t4$yvt+N`Am&B_uoCJR-E; z`Ygj-fapw0L0d1&T_zc7q}|k!ErG8OuC7$|kM=B8EE4*%rR33$Z{@t%O=f#s z5}LgW{aHS(cam};ioZ~!c38~&UQ*xW3;PDj*4W~N1Wa_Ok+*F_A6G;5n1G+prp~33 zgM~>_PMwYB)#j=tv;EHPY8crs}g1GSvJ84Aq9@wld{#DEqaD*Ag z1D#D+@O?KGmpcoa46IZxt21OSXw0;xPTz4$nuF)xp4PUp5r#Y6nWfZ%Kx%cOc%a|M zMS+~;*j^X&ILQr%F6>^IJmy%Qng8189Xa!fb~(eP$<<+^VZDLIYI!|F`aWyo06+yC{@x6xbBHqYs%!q+~B)oZhITc zXNO9y81Lj~-c_`ttR_tuHYkuVGViCO6_sTlcQj4ZPZ|WslArrB_F{ihr|=)B<9u!C zx_uR{@EZp8sxg!5+u7bVhaSUfjo%A*8?485oRll!n;Q3*eJzVg>z|Z0_9oc6RM;%0 zX7q02sD3_8BvS8~j`mhCer}!R$fm|-YEX?U?($Vgnpb=V7WMMvEj_52D)tyKsHYCz zN)+^Ny*>SfvXWLzagojyPR`s8%K^6aSg0CktCHf~R0z2q56LeGKKmGN8>TF-BV0G%4u5AQux<7sV7%1m3 zECL6eK7Rr9MoHHFScHZLASClIZ`s(&vDCEx>6eI8bnLTLqH!M`tDSs_%>f4hL*JjS z%X&x$Zj6AgbVPIqNZk=S$n%UcS4}{q4BfkDgU|m8{@QO*;!giF zE^G%Zk$~T!b#?JyJ;w5S>HGy~s_RgNWY5y__~2Py-g)Sobj3A*2EE~fx=O-805zQ@ zm{A<6lLdRvyC8E>Z8h$6vM@ybwJ+*EW|=V4mmcRFJteWTFj`U^43>JShQ?zKo5%}2={JPmWHmIEO51Yr}~&G9aKYmqMgoR ztif<)*{^uvV2JBNf^d~O>1*9o;kS{pVWR3H-O=<%;7ua?D1S1qJs}FM_0-_oJCtC8FzmWCSj$dF3DOYnBI-ns24-vRh2`Gj z-C-`EzaS%ompm<{fML5IJ@Wy#>?@3!ZiMQ_C2y7&Q9zwHNlj9Pa2S^UG=7tsObTbL zulz!GON}oAF?K$9=O)tZKukL6G%m;6gz2V$qzU}c~KZn~gAVXf3NO*)^P1j>) z*dCtIQz4AEcLBwE57HV%D})H>6quQzhVAaXnYaV92erQUM9n#F>razS{LvIOaG|>_ zS1*&bxYT5+3F;Xd)GIWPtg+Y#6F36RT0@)FzqSMNk4#WPM#`vpIzDwsfX!O`Uig6yYw(!>|r>thD;g&o1 zbkA?}c>M$j+C%diZf_GWAfMOkO;O?D@uN@N$b-V}?X*@N=1B3Rj8w|#hb)5MA$-U6 zm+|MP1i9deN1cbhEHr{3@w@ml@-sjLgZhgWVz|3pX3@f6ra@DD)gl_ztgn!Nw2*st z)D%StJl5gd{x0U#Irnw^|c;|Jr13mhs2HVlV;%=|<)tY;?>awdBS5 zR`D$m)YS88nvVpp#zzwn2u)e8;l{cs!XyWAm03?1&`@Xl-$vPI?m1$uX;0mUO5gOy zXqcp`R`O)D-p@9nLgJOD;9V@P<;(yptSP>9iuhhp{6h?*rqC|fv&~hO0)oo94seD@ z;jS;04o8cNngq>PUYnu1JV9G6#DFbg_=k|1t5lkyf?J;onj0?FKutfdaK1EQzvU*- z6?m5ZFq^0d&;Bj2i)R#ALKaFbZhH+V1$()HZV$}T;_#FjuOS$uTkdqrP0Ne&X&YTq z)(ivBfSAY%3AA|;)SN-*n;N zQgcC!b4hj1)Do++(9)ZSX3RO3xfgaK8l3lu?=eV?nYnX=5Ek9VpG;=9hf!ZNTq39~ zJ+{f|@;^FZr34zfB1Q*4`!y(MN)<2M$2l(mj?^g2T&(*D7e85b;~r!wBVBn-xpVQ> zjgI9h`6dFfxOk4!p_qJWN!@xb^T@Cf6GDkSOY9l&>XO{i0@rUz?jIdS6rje&Y+$}G zdePM#vgDvoCbQFg0Cx(pQf-y0!^>r^845;Ac0EYC#%o$mt#Vi8{ngIEhAenZ&r#%E zmIN~ps9DhL8AIVRGEd_-MV;%e9v76{gT=gOqn%exMt~dQEyvqX$eNta5Ln{!?uD#} ziMHZWWWtrMo>!vbEz0{>nnMZ~{hv3*>k}G;9C}=WrAG2tFGZ=?Q#C6OV6QF*CBZwR zlQ+VI&JgbL9u5!Lfo=T=Kf?()o4%!oN}9p|bF6y?Mf97@*VJz=pAo+ePn>qqi8A9m zB%m0w1?Eu`Z1+r=?zx(kz#QORRycAy-K}x`bP6=H4cs2^7B`uJdIIli9|S~hQPES= zaO1i!AS3W|x?B4a1w-h*TW9~8QqXfmG{0kdqg@n=k-yLO4}&jP0~;@W0SE{9W8(!n z&0vb!`Ez5h-f8lZzRfp5k_Pnk2Jn)$(Z2SQ`t*iv+Ah~*9YBwgzd5^iWJS+koZT0$H{`+dGIN2^&xz-2Lt{+Ph5)pW;0lH&PMKiXmGZ26z=>#JaXjS2{jacD;O$3a{ft#AE)?_B+wy3oAz^K z|G@fwDC^IsJcnPFpKDNd+ir}y{Q<=UPOL+m-Bu5iObYla07OdCg@$R6e$IYmP-ZxV znaB=`x86ilDxBl9#-8t4J{=;Q{y>{=Q~BG)CTl?V=>1O_rm>511W;syzckb90_q?# z_R8LEyZDLDtB07IcbEY!BXe7eK`mp);6YtIy`3Dzl={&tJcES`)Q{mJ=Dyc=7BB<_ z?qxcM)*2ZL@ip0vYdqsRX<{@3E|=i}pVjdAj8cT&^BX*UV%Sz~z`L@7G78j4k}8{+ zg(tulzJ_hnDI84A?FkV&A$o-r;@hSeC%=1YwW4>PeZbuSL<74l^pNV zutkd8);U(au*0Cf)ZV+@h@>ag?6pseNHh{%cDeyXUGO*%(D} zaa<``BwWQIESUQ;!(Kk%IUZ=e#ocai=JtXewsM!6_1TVrE)W;nR43b7w#vlv z#Tssf2%iRH6!OwBmdx$F@$TF}7V^HJ;1tswSqy;z&Lv}vjoAxjHgaIafafMt+ zmVlnO>Rr2qhoi-iM}rKL+(8kjm-{zUS?Bqx{OQSezjd*+p@o5o z(Yx~Yvzoj&ySrX@ zEUoW*$%6mgX&s!D-Hgp=BfNjq_2JQIVr}EH(-CcpOa9J#>j+ykiFfcEA>DhrP{_ve z@&(rq$+58>Zb8NT-jCUZ<+#cR?q4kqC{viy{LnTa{2?BD%C)}rrYmD}*MiYXgxY>_ zXzB?Q7q>5)`!dDZWn2or`5y>TEgSw}K>bt&N!aMN=l<3im628f&xGMQ_?xJ^72q~E z>86FM{$)1!o2>#XX;alQR5haNpKMBfVa?`zHSv5dsz*=wc1Y~%?y1{K2A`QB0~fKQ zp4WDJV*Tbm+wyb$wmubZJ(k<=R{1oDh_LxJ(5z>a9Z1xdl!ngx$T?fyrCM`lx7gvzNJqXp=H@h6E>0WsDvNWfwUdJ>0k7 zgMJU=#EP<|i>*tJ9K1wv0!w5bp`-u)RfmPnLBYn!P$9g{3W`0f7zC#C^Dskjt1$kZEtSkLK^#nNTPd7fx5`Em!rIgW{Lw$+1fxc40`A4-0 zSeYiX&M-VqWD~zj!;Lt}eJcg3f0&8cZTD%gPmxo|uiPQzgxeu&3Ew>3rj%w^o6C;t z_`4UzVw;cRQ>aLDx+F8RA|R%9e};L%+Qvx|`Y4%`VL{+xKUT-uG#EUbRNGAO4T##b!R|lkt3DAa!5Ss2c~Igo7HTx^)$GaYK)zfnPf%U;m-q?dpyTj*brEE`jWY&v}g{ z%ia)-lvbwKHXYX@>$z^z*UJ&xN{9U|%gkhvQ#Y?(lY~6l3X3{`&kb)qN|{GD1(Y_ z+?8R>PEHKvqjq*&xkGGGmBZ0!3wsTY)5P&^j+o_UD@R)rH##tOG^}k;zRG!p_F+}) zh?lIw%ZakrDrvCh+VPXoajGYbcn<)L8|t$ic)qXNSc`pHdV)S^tgw2C(7|)7+^=Yq zG2-UG?3q={xzx~abl;WK7n#}3;kd%L6ZT=p2Q)p6T!ibO?yB*d zo>OT;CSe4Dy<4lLY-hDy%se@|QthG{nxaou#UDa;wG_*A0*j`KRy zwGp_i)~}WN;tikbYgKair@XSFdyU@Ihocv%{_s3tUpG z<*3M0yJtN7g_)+)hq$6eyBcDRr}SCqvanOxQDXj$I9Se}G+%%Hp6VH0G;la|pLqUK zF#I&smnjh)<5kBp3?D-MiSt%}#&7GBSzpwhybf?aprPok$Mz>GN9Yl~t%kOV=Uj-N zS4{NEOrFqx+7$VTWd;B6wB!{@^c@!rY*gb!##yLPiAd7KyI+vo6@axaguisadLN&@ z^ELN%VMgvsTXY}5NG_gPqU9$bZ7l?^65eiS!gyDEF6@Zj^EL0XOaFed*o`snr|sQk zx&hb|c#gi=_{D2*2C-7J&$3Mov8S#=dTGe|yzRH`p0T+RWe1$3t(b-$I||+v#_N7b zBDHq&GoWnWB6`8wRFDUaLoy%6eRKhv&MWpl%#SU2PHTQMINoel+W+v&L1fs(mD1e1 z+S(jpys?*3bfWFFuBOb{%oo~>jGj=>Kp!)*VbqU;`p_8E=987}X(nQ)0eQ`eg}mEb zI;@J7KY7)+LE+|JFQwAE3EjJKC5ipEzhQMiR52;rf+j0JZ;R}&i!oQb)iK{#?us$k zHVbHr@?WwRI!N&<16 z@j+pln%7Ivvc)WXB*xl7l;Vl#U=y?qn-3r5&ldB)dW*->dVhPonHBomhg{u1!-Rw$ zF-2q}_Rn{Rh&%X_M@WXw+kAw~6KX6nVpbC8j+zqm%|*ROt}Kt`;#-IHfl|J8?F!;k zFs%0Kvwf=RqPk<$=GZhdVaaqD;i^6^b$Gpre!$Iwo`xd7#(3cK|J>#>)%&(7RcG6* zkMnZTtZnkPptbUI;e!-W&dp3=cJqQ}-CyJTar@Ah%vYTCU38zp?GFg;TS#b0C{4HX zlh243w3L^%e2eUhtKP!RR^hE_p|7#E=Mk~FRFh3Ne@pF5?Tp0k}dldDk*yWqvJIk)v1L&9u?`s`Ya?L{+4|jQCQChizrXMI_s8$AUX0GU&wcK>&vm`8&-FQK zwMs&PgRVOr%b1ZD4#;7Jg{Ngxe#tW^<0ZmkwVKXkV9z_UVh6(l6K-<+8PM5EV^*D2 zn8wvbj@B!of2HFn_EBUAbZ)!D-36yUW6NG`H^=$1gJ+GYZA#R$H}mQT(ECgf_^VG# z7-Ns3Rt1f!hSl-74zKuYsN(C2+!!y!L&dG7278RAf^y1;_!_&r{`Av5b$xbsSOr+=oPh7l?2;>Dea`qWrSV zIE;z4dCcZ4wR86h9!VcSxV=vHWYa%cEXwylxR=t9*V%A^pz0GVEicb!LUh+$DiE@i z+lSXZkD%c_KQI9$WXI{O#cg4p;)AZaqI{>k$UW>v?>gxyJ*0k0{C3_E zYEe^qHZz)F?Y4Eoj*^QPM}Xr~hDJ#d^17kKo_*=$dWzfv&hyIrpII#wcK;?XjfQFr zi0L^O`!h0`Tx!Ca(Z5M-N6J@*sb!NQc0n?f(qa|w|6j6tzsad(!{1?vj_MQYQ0fd3 z7>E)52T(_CEy-VpGHvFtq6Zs=gnx%*{$2fnnpaaKJW#zPdZShX!ILni)#ZX|lE42-H)rODL!om5ZgZOg?@a;0Ec+59^hbO1YG~Mf z9O~+q#k@!@onJM(dN}$qJ^P?Tuy>Z{iJm{vypTH8w>70(A}`R)unA&H(jqbk23-w< zn=$JBNmmP!K~}kedZ4d5bpOB!Ko7v@;xBQy8ujnM420+Dm=M%W=jI=knUB=WuW_?J3={w!e@7^Y5b5;M1w|wA-0>?L-;(TUXLS(5G#$d?63c@SGCrbGH zB_*SEL}3)7uKQY9zsU?Xjkgo_+B{Pbt9#uJ?enIUlK$F)pm+5YxVUi^rEn2{mPnL9kj-hTtUB}4euZ;q_wn^w$xV%*leCPg{D zJ{)79I}>|dEzrKCq<&Y^gWD#8S+&+mISYqvX0tsy44OD)#Y9;2VN}7N(dCyMWiC+-|&}& zsZPNaS`9*vqJgxd({e@?fe@Oe_5;66GX=yBrhKA%HK=?kDvaoLkgw~ zdy9;wI(%*c`JUG9wud050groV+@k+vFQQ=GysIt>0GrNZMlNc%B)9v+qT-~l@7=_@1M?i) zWbJ)Y&<-<>5%*IIOckGz``z#bE8%Y>$o+wr`{WkWqdcq-ZUW@&xqPYUPNHX=Y7m@L z45hX_V-TfgwN6~X^~oI(-Zw1^J7+l^PYoQB&%j2e+u?VCo65C$KSO-qo!Ju>{`{2Y zmNsnjS>1e|>0>QP_|dVE^S*~Tuq(^|MOJX3KlCp^U{zOaPu^Kjqrtwv>-l$vqb7e<*|u$_HXmz7(> z)p}LDcPX3Hpoxd%s{bWf`3b?M0)Kw&+1x3{+s?BdLnivm634*M-RGGn(f+n$_UL4* zsc*Tp?UkbBs{=+*vrNrir2z)K?UMhe+GY&=O$?$9jl1w9hmh~lQ>|s8uO;b2gVDbopL3F}Wy zkdk<93k`YR>g9F*GX}Ht2noFkR$D6{OAAnpJxoPLLD=aG3R zBNQ2RU$&(^Mv-0BYfu*L=NRwKd5EC12+Cws++%N8T8Z}oXlUWt@UH*Czaht{&@-{ zlBg_wV(R?P+F&G25a!6;cYOVTP*#$Wra zw@42+n_nGkFLp;K6!77_NSe9OdF5tW70nRnvyH0Lsdn3rCOo!TA1u!9NhfGC;-Qd< z<}&4wX4`q{f10||6iX1kB(C!-VWv5~|B%?+J{CWrbR*qYkxiY3xfc#t1M&me)I3#q zxlr-e3dw7YZimJzP8n~{z|u<%gER>Ztp7~ohte1Ve&D=^K;L!cIheM~SZ2=r*bmb5 zzAX5?4N`B!YFCtnNDEgNvD})=f^TgvR@V2f(L78Us>mD4P{-ILxeNH+t<26^6#~Fd0cwKY4Ir@391!@!`b1Y zn!vK>@|3QU7mZ20GU@orgDwz1d1MaQ56-+3d@9G9u3ZIC%v9>3-Amkx7ebrUrdmul zF%nEDz!FgT^5?Md2_N`E$&1_G4qkE7f3l#`Q8*LuQRJ=VuXH5jz&ag?Joxn}+&>Co z`7$39x**l`ej)`|ecTG$lbTQhPm6sy6{CD1$oXNP#=dCRFpyt>%uH~~IG~XslhQ&01o~!zM<=m(`0~E6@pY0*=4hF8|y>E)~P|H==8)w9- z@!;I03Ih+Gx9_CMmpYL*CSjWC-`_q5du zrPk|G>b9exK2kmWIr8N6Hyx=xNP!PY%9OJ;#V;gwI?7QCRU6?b6v(%pq#zPc=3+Q^ z1MkTAQd4spkLC|2pfdY~`e5dhy10(w#M^hGBmE4CDru9Wx5lkrVj&|St5XOQ^_?2U z-Mkt-xXyyMd+4K_FYHexJ9{6)cFwtd&91wtC75>U+B2qzJT~;}zC)(oFEaR?$Y7s3 zQ_V7K^|7OvQjdlT9l~ag)d>=;BY}Sx;u;eQm4lm2YpO@(JZ#SGmrY|vD*r$$X9HjM zQ;Jel<_$z^<=;BG-iO2df!bmB39wKs2ZMB<@NU}dl+zG;9TTq4O61yr_8I)3YN3OEp`%k75tNH{8&*?nHLBdLa1cr3Z>Hi#sMIg%uPua zs4+9JFWp1oQm#;H_@hMtw50yBQ(Pq;s8PSK_llBe_nz}U7rhC#LJ5vJ%CUR)J^^xI z^gTJ;EZsat(+=%V=bdgInBJ##<7YA-@XxIM2K#DKCD2p?4g@lKNC>-Q9RY3YJ_yOR zxTzI!21t*f4CILdXMZYX|MF|m1ZHhW1^7Gt0+7iRvHweu0uTknL)K-JR1GMALhC$3 zlHq&Hz_0olXys3Dto(JICZtRI@5D5}C~xb+{8J50DV=B0;d?)%ye7C--kOrv$}?%SzKgWs1{s^qmU4e{#j5 z|Av|O_ug{k&FxzRPdokb0%(-ff`WmhI4e}BJ4jxf9}=0?>KXNcw_FVay%oYfVswiL zB$z~jHyO}Y?t88V38|_;OH|(RqC&1O4XLFIUga!CkX5}lcr(@tej@WY|4)Bx3H>pw zk1H!Z46|(Bu_H`ji|#3>KW;$Es@kj2xkH2q(7DIy%V1O=OCAlUc_*r^-la;I(9G zNbn9j29`ws8$iURgmASfy8L+5`Cx`0>A7Ge0l2 zU%md)Z(6 z#7^_qTtWBI)+~jM5w6#i10updoY|7+%Z@(sZyUo&zFoWAD}3G zCgTfn2^8#i17N@U&DgKI2PWiE-wB)-x%NG~OMchsh}@zls8`o%?h#QOwWtQoFboS$ zWk}ytb8Y~5)B5d?N`UiPhQt@11$wW`Kr2cWsX^-j#1PG?F$7>eYf`RJ`$&r2E6gm) zob(vj(q1SbKF|zTu!fV3Z9acc^dsAMtw?N(9ERL#{Vh>kwmRN08ISsBcU>nLD z+H3tp-6`^nlcL5ZncR+Oy+u>!eyML?pXQK?^60)B*{`J0 zCb^R{d{~sW=EECtOsG#L^9Am+_p1DM0#(-4ipdrKX;7RG2PXBkwT&0vhB7_LN(Zti z;$nJCli^~VN5*p@bJ3$&b;EhtQfN45&xyt2boAFHtteAt0rwtEbV0T5JgbbP!s8^g zm_mtUuE3Dj^ z1nm7>F!N;hCLOcN?Lk%VFBU#+w+dgr_S}4IxK8E%oY;*sg8F1b+@hzgp1sL`BEE_d zCX*eAvd>hF!><_1vc-2Bh&IuVGW6Iut;w%c7%>OmjFGD_iZ^H~4fZnuTId-%a59D} zT@3{9G2Onu|5~MJ-+lrA4nkxeuD06nrtr-?p)`I9|3`m$OxsrWT21)hRhxP`fDW3%3>(-8cSjWk37(eCCVr{>_TB>Z0|~OVo;Ao5_w5{8|9Xa51=#K{zlVDOY$_vp-gB; z_f_KYaZ8-UEnJm@?@JETV<+w#oFiq&3Y|O?pznWawkesGrc~psMa@e@86=klk7?e>F|SFe?=< zYnJF|ozih6Huzjd^zmuwJL2UX2GjFCA4@P!yt=3x_2%kj3WFnyUpKcT4gP(}Qbgzp zRx#!JA7ZEi#OPn#GO>9x14JG=8TmSnYa-Q5>Q3&h0+=1NqpzTVEkf z<8mF#4D-o~BJXuulV9cC2BX|*4p1R#0~O{F6x@)iut`@{sPIy?aBxU4HetZHsy*q1 zbSwO2Fc*;`!TQ^Lj-9vEdCKS; zG}QJ3;RviYqS>ib=3C*;mG*4Aj~5}o#ZLeg#kGt2UX&}VTY6@hcjN+ai^r2OoRQ=-yG1 zOX?i0b^irJL&hfeB0_6UE;MeBIZg$HidLO{s7YFFD4BLN26T%+aS8PFaPChp_Ao?> z-~<>m`+y^Lbr_Jbn70e~-jMXQ_|mZyjTJ@Cl-FI1BQO9N$llBHh6U3zFFjY;{xs^o zx4+llJ9_e>6rKjDSc31uC@IWk_k9^5s*yPr+62~^S~G+Iqg%Z$vdW`GaE@(Km!W(Q zJdQ-0lw*0#QaLJR?S*B|UuR?bV2xj`<&`;487rRS(!R;rv|^3+Yb4J0YHeZ|skg9E zm#T&YiPjDVeFW?LWXq%w;D`YZLWLDK4m}krHbqJ`fs24Fh~&KV`jBjmmP;WVyR&qj zglI4Zj$@d?IuS(=xj2s%SlW#Uk(-3iyA|Ucq;wqzj|6cVZxXuMu}s#Q{S8DO2&ReU z%q}IY#Kv4F)hk%;XHI-O5>TL$@Oo*6|1!686RkA|dIIxhDAykF8Vubn+EG(Vhnzhd zSSr_#d224(ybj@V?ScG^Z0ewy);uv0ibO?t{~7C2nRH@$sMpP(D!UqH5s%)5xrXxS z6g0u;#DB5AkUyUjLgB`PfvM;xptMFE*kDW1TeYQwIFJ(;pHQrosUJQp(_Hjsz`l`3 zM=N49c6Y8#1C~dI=_#aVS|1cO(Kxd4BVzb& zR0n*SRIqIXTrn28U;=SPmJ@GdMFomZ*1@dp-eNi4;FVift`M)5d|IZOb-Q?q)Qjj% zc^3rYP4&GGjM~m!vK_3%hQ3mhzJ-O0==TGoeCDAeXbx%EXbToHOK)q@MFMOIrug2j z3HS}{VU0U#lqkFzYz|#HUb6H}vkjb~FKMm0lEav)b~?j!9O;|<2TG4`>ZG8=%Qi29 zxA*nR6K0CoREi9}mmy0|rKOOT_;Yf0?DYvT&!uA{{!->SX@ENR11=&{09=f^&J@VT zkm4-nKEraw>NN0V3znSSD(YTE=o0qPRbO%$R7nGHvDxo21Q&%00bHDPZ<_A;0T*9& zb1u7dX9cTs#J;0zF--rAm{Qx19`kiu$~{SUHWm_=;hVtjy+?c;((k!39+IdQ8d53J zrlw9{GkNXaSAW{+nYD7ItTul{&6$!%tRlysI+BmmH`yvw-oCOPFG5w>g(|z@YK@0b zdrM*MxpOy@GI`iZ1j4kA-;U1Qt)Q!Xu)N2JHo4#Xo4-gx>rmP?+`Q#EGN8V-cI z6}G`exFI_!5hG6RL-)e6g>f$v_ddUg8jUMV6SB=<^w2nIi)U6DS}+b3nj9a_<3UTJ zo}7!ittc^~M|AP<@SFxB@(MguNXaRf*O&OpW5kD|BstJZLlf#nZTB~XsoJI`NLvOm zCkE9;Na@lyi8Tk+dQ*;tWWI%;OHpSA$W(ZIe9CEpmp$uq{zV zq@f;PoH|FV-b5qbydBumZs@Zlfj$csFSp0kHdjI6!WvqPk_Bi{lEcgLVq+>78E=b7~hP>mHTzNE`SH?2v=fCd;D$Aa?>it{Ty@(en`SH%(qAb$9;)0Y-@b_%gN_**0iSJGi74gYp9l~}kh42hY!JpNNkAC0)c@TX ze+2^1uYcs)pLq8NEMNisY+20Ib{!f4g};O#QyVrO*4`a!d;ln^^1wSqq4pMPgY%>X zgbg Date: Mon, 21 Mar 2022 23:01:08 +0000 Subject: [PATCH 056/827] Clean up some existing blog articles These updates bring older articles in line with current styling for author attributions, etc. --- .../2015-03-00-Welcome-To-Kubernetes-Blog.md | 8 ++-- .../2015-05-00-Kubernetes-Release-0160.md | 2 +- .../2015-05-00-Kubernetes-Release-0170.md | 2 +- ...-Announcing-First-Kubernetes-Enterprise.md | 3 +- ...mproved-Tooling-And-A-Growing-Community.md | 6 ++- ...Kubecon-Eu-2016-Kubernetes-Community-In.md | 33 ++++++++------- ...-Application-Deployment-And-Management-.md | 25 +++++------ ...g-Cloud-Native-And-Enterprise-Workloads.md | 19 ++++----- ...00-Kubernetes-18-Security-Workloads-And.md | 8 +++- ...ernetes-19-Workloads-Expanded-Ecosystem.md | 7 +++- ...stabilizing-storage-security-networking.md | 7 +--- ...-2018-north-american-contributor-summit.md | 24 +++++------ ...tore-For-Kubernetes-Contributor-Summits.md | 21 ++++------ ...-05-02-kubecon-diversity-lunch-and-hack.md | 2 +- ...2019-09-24-san-diego-contributor-summit.md | 12 +++--- ...0-contributor-summit-san-diego-schedule.md | 12 ++---- ...tor-Summit-Amsterdam-Schedule-Announced.md | 41 +++++++++---------- .../2020-03-04-Contributor-Summit-Delayed.md | 4 +- 18 files changed, 116 insertions(+), 120 deletions(-) diff --git a/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md b/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md index 54e4fbe4ad..6acce95939 100644 --- a/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md +++ b/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md @@ -1,9 +1,12 @@ --- -title: Welcome to the Kubernetes Blog! +title: Welcome to the Kubernetes Blog! date: 2015-03-20 slug: welcome-to-kubernetes-blog url: /blog/2015/03/Welcome-To-Kubernetes-Blog --- + +**Author:** Kit Merker (Google) + Welcome to the new Kubernetes Blog. Follow this blog to learn about the Kubernetes Open Source project. We plan to post release notes, how-to articles, events, and maybe even some off topic fun here from time to time. @@ -25,6 +28,3 @@ To start things off, here's a roundup of recent Kubernetes posts from other site Happy cloud computing! - - - - Kit Merker - Product Manager, Google Cloud Platform diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md index abe97435eb..e070945501 100644 --- a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md +++ b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md @@ -1,5 +1,5 @@ --- -title: " Kubernetes Release: 0.16.0 " +title: "Kubernetes Release: 0.16.0" date: 2015-05-11 slug: kubernetes-release-0160 url: /blog/2015/05/Kubernetes-Release-0160 diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md index 29d86abe6d..c326392c95 100644 --- a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md +++ b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md @@ -1,5 +1,5 @@ --- -title: " Kubernetes Release: 0.17.0 " +title: "Kubernetes Release: 0.17.0" date: 2015-05-15 slug: kubernetes-release-0170 url: /blog/2015/05/Kubernetes-Release-0170 diff --git a/content/en/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md b/content/en/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md index 98b4c49d67..ae0b3f8f39 100644 --- a/content/en/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md +++ b/content/en/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md @@ -1,9 +1,10 @@ --- -title: " Announcing the First Kubernetes Enterprise Training Course " +title: "Announcing the First Kubernetes Enterprise Training Course" date: 2015-07-08 slug: announcing-first-kubernetes-enterprise url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise --- + At Google we rely on Linux application containers to run our core infrastructure. Everything from Search to Gmail runs in containers.  In fact, we like containers so much that even our Google Compute Engine VMs run in containers!  Because containers are critical to our business, we have been working with the community on many of the basic container technologies (from cgroups to Docker’s LibContainer) and even decided to build the next generation of Google’s container scheduling technology, Kubernetes, in the open. diff --git a/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md b/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md index 754f6319e0..5e433c180b 100644 --- a/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md +++ b/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md @@ -1,9 +1,12 @@ --- -title: " Kubernetes 1.1 Performance upgrades, improved tooling and a growing community " +title: "Kubernetes 1.1 Performance upgrades, improved tooling and a growing community" date: 2015-11-09 slug: kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community url: /blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community --- + +**Author:** David Aronchick (Google) + Since the Kubernetes 1.0 release in July, we’ve seen tremendous adoption by companies building distributed systems to manage their container clusters. We’re also been humbled by the rapid growth of the community who help make Kubernetes better everyday. We have seen commercial offerings such as Tectonic by CoreOS and RedHat Atomic Host emerge to deliver deployment and support of Kubernetes. And a growing ecosystem has added Kubernetes support including tool vendors such as Sysdig and Project Calico. With the help of hundreds of contributors, we’re proud to announce the availability of Kubernetes 1.1, which offers major performance upgrades, improved tooling, and new features that make applications even easier to build and deploy. @@ -50,4 +53,3 @@ As we mentioned above, we would love your help: But, most of all, just let us know how you are transforming your business using Kubernetes, and how we can help you do it even faster. Thank you for your support! - - David Aronchick, Senior Product Manager for Kubernetes and Google Container Engine diff --git a/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md b/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md index 38ee6129fd..9150ae36e6 100644 --- a/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md +++ b/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md @@ -1,37 +1,40 @@ --- -title: " KubeCon EU 2016: Kubernetes Community in London " +title: "KubeCon EU 2016: Kubernetes Community in London" date: 2016-02-24 slug: kubecon-eu-2016-kubernetes-community-in url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In --- -KubeCon EU 2016 is the inaugural [European Kubernetes](http://kubernetes.io/) community conference that follows on the American launch in November 2015. KubeCon is fully dedicated to education and community engagement for[Kubernetes](http://kubernetes.io/) enthusiasts, production users and the surrounding ecosystem. +**Author:** Sarah Novotny (Google) + +KubeCon EU 2016 is the inaugural European Kubernetes community conference that follows on the American launch in November 2015. KubeCon is fully dedicated to education and community engagement for [Kubernetes](/) enthusiasts, production users and the surrounding ecosystem. Come join us in London and hang out with hundreds from the Kubernetes community and experience a wide variety of deep technical expert talks and use cases. Don’t miss these great speaker sessions at the conference: -* “Kubernetes Hardware Hacks: Exploring the Kubernetes API Through Knobs, Faders, and Sliders” by Ian Lewis and Brian Dorsey, Developer Advocate, Google -* [http://sched.co/6Bl3](http://sched.co/6Bl3) +* “Kubernetes Hardware Hacks: Exploring the Kubernetes API Through Knobs, Faders, and Sliders” by Ian Lewis and Brian Dorsey, Developer Advocate, Google [https://sched.co/6Bl3](http://sched.co/6Bl3) -* “rktnetes: what's new with container runtimes and Kubernetes” by Jonathan Boulle, Developer and Team Lead at CoreOS -* [http://sched.co/6BY7](http://sched.co/6BY7) +* “rktnetes: what's new with container runtimes and Kubernetes” by Jonathan Boulle, Developer and Team Lead at CoreOS [https://sched.co/6BY7](http://sched.co/6BY7) -* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google -* [http://sched.co/6BUP](http://sched.co/6BUP)  -* “[What is OpenStack's role in a Kubernetes world?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” By Thierry Carrez, Director of Engineering, OpenStack Foundation -* http://sched.co/6BYC -* “A Practical Guide to Container Scheduling” by Mandy Waite, Developer Advocate, Google -* [http://sched.co/6BZa](http://sched.co/6BZa) +* “Kubernetes Documentation: Contributing, fixing issues, collecting bounties” by John Mulhausen, Lead Technical Writer, Google [https://sched.co/6BUP](http://sched.co/6BUP)  -* “[Kubernetes in Production in The New York Times newsroom](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis, Web Developer, New York Times -* [http://sched.co/67f2](http://sched.co/67f2) -* “[Creating an Advanced Load Balancing Solution for Kubernetes with NGINX](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” by Andrew Hutchings, Technical Product Manager, NGINX -* http://sched.co/6Bc9 -* And many more http://kubeconeurope2016.sched.org/ +* “[What is OpenStack's role in a Kubernetes world?](https://kubeconeurope2016.sched.org/event/6BYC/what-is-openstacks-role-in-a-kubernetes-world?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” By Thierry Carrez, Director of Engineering, OpenStack Foundation [https://sched.co/6BYC](http://sched.co/6BYC) + +* “A Practical Guide to Container Scheduling” by Mandy Waite, Developer Advocate, Google [https://sched.co/6BZa](http://sched.co/6BZa) + +* “[Kubernetes in Production in The New York Times newsroom](https://kubeconeurope2016.sched.org/event/67f2/kubernetes-in-production-in-the-new-york-times-newsroom?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” Eric Lewis, Web Developer, New York Times [https://sched.co/67f2](http://sched.co/67f2) + +* “[Creating an Advanced Load Balancing Solution for Kubernetes with NGINX](https://kubeconeurope2016.sched.org/event/6Bc9/creating-an-advanced-load-balancing-solution-for-kubernetes-with-nginx?iframe=yes&w=i:0;&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no)” by Andrew Hutchings, Technical Product Manager, NGINX [https://sched.co/6Bc9](https://sched.co/6Bc9) + +…and many more https://kubeconeurope2016.sched.org/ -Get your KubeCon EU [tickets here](https://ti.to/kubecon/kubecon-eu-2016). +~Get your KubeCon EU [tickets here](https://ti.to/kubecon/kubecon-eu-2016)~. Venue Location: CodeNode * 10 South Pl, London, United Kingdom Accommodations: [hotels](https://skillsmatter.com/contact-us#hotels) Website: [kubecon.io](https://www.kubecon.io/) Twitter: [@KubeConio](https://twitter.com/kubeconio) #KubeCon + Google is a proud Diamond sponsor of KubeCon EU 2016. Come to London next month, March 10th & 11th, and visit booth #13 to learn all about Kubernetes, Google Container Engine (GKE) and Google Cloud Platform! - -_KubeCon is organized by KubeAcademy, LLC, a community-driven group of developers focused on the education of developers and the promotion of Kubernetes._ - --* Sarah Novotny, Kubernetes Community Manager, Google diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md index c63763d4e5..de05def28e 100644 --- a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md +++ b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md @@ -1,17 +1,19 @@ --- -title: " Kubernetes 1.2: Even more performance upgrades, plus easier application deployment and management " +title: "Kubernetes 1.2: Even more performance upgrades, plus easier application deployment and management" date: 2016-03-17 slug: kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management url: /blog/2016/03/Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management --- -Today we released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet. +**Author:** David Aronchick (Google) + +Today the Kubernetes project released Kubernetes 1.2. This release represents significant improvements for large organizations building distributed systems. Now with over 680 unique contributors to the project, this release represents our largest yet. From the beginning, our mission has been to make building distributed systems easy and accessible for all. With the Kubernetes 1.2 release we’ve made strides towards our goal by increasing scale, decreasing latency and overall simplifying the way applications are deployed and managed. Now, developers at organizations of all sizes can build production scale apps more easily than ever before.  -### What’s new:  +## What’s new - **Significant scale improvements**. Increased cluster scale by 400% to 1,000 nodes and 30,000 containers per cluster. -- **Simplified application deployment and management**.  +- **Simplified application deployment and management**. - Dynamic Configuration (via the ConfigMap API) enables applications to pull their configuration when they run rather than packaging it in at build time.  - Turnkey Deployments (via the Beta Deployment API) let you declare your application and Kubernetes will do the rest. It handles versioning, multiple simultaneous rollouts, aggregating status across all pods, maintaining application availability and rollback.  @@ -28,15 +30,15 @@ From the beginning, our mission has been to make building distributed systems ea - **And many more**. For a complete list of updates, see the [release notes on github](https://github.com/kubernetes/kubernetes/releases/tag/v1.2.0).  -#### Community  +## Community -All these improvements would not be possible without our enthusiastic and global community. The momentum is astounding. We’re seeing over 400 pull requests per week, a 50% increase since the previous 1.1 release. There are meetups and conferences discussing Kubernetes nearly every day, on top of the 85 Kubernetes related [meetup groups](http://www.meetup.com/topics/kubernetes/) around the world. We’ve also seen significant participation in the community in the form of Special Interest Groups, with 18 active SIGs that cover topics from AWS and OpenStack to big data and scalability, to get involved [join or start a new SIG](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)). Lastly, we’re proud that Kubernetes is the first project to be accepted to the Cloud Native Computing Foundation (CNCF), read more about the announcement [here](https://cncf.io/news/announcement/2016/03/cloud-native-computing-foundation-accepts-kubernetes-first-hosted-projec-0).  +All these improvements would not be possible without our enthusiastic and global community. The momentum is astounding. We’re seeing over 400 pull requests per week, a 50% increase since the previous 1.1 release. There are meetups and conferences discussing Kubernetes nearly every day, on top of the 85 Kubernetes related [meetup groups](http://www.meetup.com/topics/kubernetes/) around the world. We’ve also seen significant participation in the community in the form of Special Interest Groups, with 18 active SIGs that cover topics from AWS and OpenStack to big data and scalability, to get involved [join or start a new SIG](https://github.com/kubernetes/kubernetes/wiki/Special-Interest-Groups-(SIGs)). Lastly, we’re proud that Kubernetes is the first project to be accepted to the Cloud Native Computing Foundation (CNCF), read more about the announcement [here](https://cncf.io/news/announcement/2016/03/cloud-native-computing-foundation-accepts-kubernetes-first-hosted-projec-0). -#### Documentation  +## Documentation -With Kubernetes 1.2 comes a relaunch of our website at [kubernetes.io](http://kubernetes.io/). We’ve slimmed down the docs contribution process so that all you have to do is fork/clone and send a PR. And the site works the same whether you’re staging it on your laptop, on github.io, or viewing it in production. It’s a pure GitHub Pages project; no scripts, no plugins.  +With Kubernetes 1.2 comes a relaunch of our website at [kubernetes.io](http://kubernetes.io/). We’ve slimmed down the docs contribution process so that all you have to do is fork/clone and send a PR. And the site works the same whether you’re staging it on your laptop, on github.io, or viewing it in production. It’s a pure GitHub Pages project; no scripts, no plugins. @@ -48,7 +50,7 @@ To entice you even further to contribute, we’re also announcing our new bounty -#### Roadmap  +## Roadmap All of our work is done in the open, to learn the latest about the project j[oin the weekly community meeting](https://groups.google.com/forum/#!forum/kubernetes-community-video-chat) or [watch a recorded hangout](https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ). In keeping with our major release schedule of every three to four months, here are just a few items that are in development for [next release and beyond](https://github.com/kubernetes/kubernetes/wiki/Release-1.3):  @@ -64,7 +66,7 @@ Kubernetes 1.2 is available for download at [get.k8s.io](http://get.k8s.io/) and -#### Connect  +## Connect We’d love to hear from you and see you participate in this growing community:  @@ -73,8 +75,7 @@ We’d love to hear from you and see you participate in this growing community:& -  Connect with the community on [Slack](http://slack.kubernetes.io/)  - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates  -Thank you for your support!  +Thank you for your support! - - _David Aronchick, Senior Product Manager for Kubernetes, Google_ diff --git a/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md index 13e682c0a8..74f9a41db1 100644 --- a/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md +++ b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md @@ -1,9 +1,12 @@ --- -title: " Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads " +title: "Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads" date: 2016-07-06 slug: kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads url: /blog/2016/07/Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads --- + +**Author:** Aparna Sinha, Google + Nearly two years ago, when we officially kicked off the Kubernetes project, we wanted to simplify distributed systems management and provide the core technology required to everyone. The community’s response to this effort has blown us away. Today, thousands of customers, partners and developers are running clusters in production using Kubernetes and have joined the cloud native revolution.  Thanks to the help of over 800 contributors, we are pleased to announce today the availability of Kubernetes 1.3, our most robust and feature-rich release to date. @@ -14,7 +17,7 @@ Product highlights in Kubernetes 1.3 include the ability to bridge services acro -**What’s new:** +## What’s new - **Increased scale and automation** - Customers want to scale their services up and down automatically in response to application demand. In 1.3 we have made it easier to autoscale clusters up and down while doubling the maximum number of nodes per cluster. Customers no longer need to think about cluster size, and can allow the underlying cluster to respond to demand. @@ -31,13 +34,13 @@ Product highlights in Kubernetes 1.3 include the ability to bridge services acro - **Updated Kubernetes dashboard UI** - Customers can now use the Kubernetes open source dashboard for the majority of interactions with their clusters, rather than having to use the CLI. The updated UI lets users control, edit and create all workload resources (including Deployments and PetSets). - And many more. For a complete list of updates, see the [_release notes on GitHub_](https://github.com/kubernetes/kubernetes/releases/tag/v1.3.0). -**Community** +## Community We could not have achieved this milestone without the tireless effort of countless people that are part of the Kubernetes community. We have [19 different Special Interest Groups](https://github.com/kubernetes/community/blob/master/README.md#special-interest-groups-sig), and over 100 meetups around the world. Kubernetes is a community project, built in the open, and it truly would not be possible without the over 233 person-years of effort the community has put in to date. Woot! -**Availability** +## Availability Kubernetes 1.3 is available for download at [get.k8s.io](http://get.k8s.io/) and via the open source repository hosted on [GitHub](http://github.com/kubernetes/kubernetes). To get started with Kubernetes try our [Hello World app](/docs/hellonode/). @@ -47,7 +50,7 @@ To learn the latest about the project, we encourage everyone to [join the weekly -**Connect** +## Connect We’d love to hear from you and see you participate in this growing community: @@ -58,8 +61,4 @@ We’d love to hear from you and see you participate in this growing community: -Thank you for your support!  - - - --- Aparna Sinha, Product Manager, Google +Thank you for your support! diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md b/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md index d8f09da298..00ed354d86 100644 --- a/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md +++ b/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md @@ -4,7 +4,8 @@ date: 2017-09-29 slug: kubernetes-18-security-workloads-and url: /blog/2017/09/Kubernetes-18-Security-Workloads-And --- -_Editor's note: today's post is by Aparna Sinha, Group Product Manager, Kubernetes, Google; Ihor Dvoretskyi, Developer Advocate, CNCF; Jaice Singer DuMars, Kubernetes Ambassador, Microsoft; and Caleb Miles, Technical Program Manager, CoreOS on the latest release of Kubernetes 1.8._ + +**Authors:** Kubernetes v1.8 release team We’re pleased to announce the delivery of Kubernetes 1.8, our third release this year. Kubernetes 1.8 represents a snapshot of many exciting enhancements and refinements underway. In addition to functional improvements, we’re increasing project-wide focus on maturing [process](https://github.com/kubernetes/sig-release), formalizing [architecture](https://github.com/kubernetes/community/tree/master/sig-architecture), and strengthening Kubernetes’ [governance model](https://github.com/kubernetes/community/tree/master/community/elections/2017). The evolution of mature processes clearly signals that sustainability is a driving concern, and helps to ensure that Kubernetes is a viable and thriving project far into the future. @@ -50,7 +51,7 @@ The [Release team](https://github.com/kubernetes/features/blob/master/release-1. As the Kubernetes community has grown, our release process has become an amazing demonstration of collaboration in open source software development. Kubernetes continues to gain new users at a rapid clip. This growth creates a positive feedback cycle where more contributors commit code creating a more vibrant ecosystem. -## User Highlights +## User highlights According to [Redmonk](http://redmonk.com/fryan/2017/09/10/cloud-native-technologies-in-the-fortune-100/), 54 percent of Fortune 100 companies are running Kubernetes in some form with adoption coming from every sector across the world. Recent user stories from the community include: @@ -91,3 +92,6 @@ The simplest way to get involved with Kubernetes is by joining one of the many [ - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates - Chat with the community on [Slack](http://slack.k8s.io/). - [Share your Kubernetes story.](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) + + +_Editor's note: this announcement was authored by Aparna Sinha (Google), Ihor Dvoretskyi (CNCF), Jaice Singer DuMars (Microsoft), and Caleb Miles (CoreOS)._ diff --git a/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md b/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md index cb73d95162..8f3671300b 100644 --- a/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md +++ b/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md @@ -1,9 +1,12 @@ --- -title: " Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem " +title: "Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem" date: 2017-12-15 slug: kubernetes-19-workloads-expanded-ecosystem url: /blog/2017/12/Kubernetes-19-Workloads-Expanded-Ecosystem --- + +**Authors:** Kubernetes v1.9 release team + We’re pleased to announce the delivery of Kubernetes 1.9, our fourth and final release this year. Today’s release continues the evolution of an increasingly rich feature set, more robust stability, and even greater community contributions. As the fourth release of the year, it gives us an opportunity to look back at the progress made in key areas. Particularly notable is the advancement of the Apps Workloads API to stable. This removes any reservations potential adopters might have had about the functional stability required to run mission-critical workloads. Another big milestone is the beta release of Windows support, which opens the door for many Windows-specific applications and workloads to run in Kubernetes, significantly expanding the implementation scenarios and enterprise readiness of Kubernetes. @@ -87,7 +90,7 @@ For recorded sessions from the largest Kubernetes gathering, [KubeCon + CloudNat ## Webinar -Join members of the Kubernetes 1.9 release team on **January 9th from 10am-11am PT** to learn about the major features in this release as they demo some of the highlights in the areas of Windows and Docker support, storage, admission control, and the workloads API. [Register here](https://zoom.us/webinar/register/WN_oVjQMwyzQFOmWsfVzDsa2A). +Join members of the Kubernetes 1.9 release team on **January 9th from 10am-11am PT** to learn about the major features in this release as they demo some of the highlights in the areas of Windows and Docker support, storage, admission control, and the workloads API. [~Register here~](https://zoom.us/webinar/register/WN_oVjQMwyzQFOmWsfVzDsa2A). ## Get involved: diff --git a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md index 922ec9f706..a802e6f20c 100644 --- a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md +++ b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md @@ -1,13 +1,8 @@ --- -title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking ' -author: kbarnard -tags: +title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking' date: 2018-03-26 modified_time: '2018-03-27T11:01:39.569-07:00' -blogger_id: tag:blogger.com,1999:blog-112706738355446097.post-6519705795358457586 -blogger_orig_url: https://kubernetes.io/blog/2018/03/26/kubernetes-1.10-stabilizing-storage-security-networking/ slug: kubernetes-1.10-stabilizing-storage-security-networking -date: 2018-03-26 --- ***Editor's note: today's post is by the [1.10 Release diff --git a/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md b/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md index 095e47a73d..53846e6cee 100644 --- a/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md +++ b/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md @@ -1,13 +1,11 @@ --- -layout: "Blog" +layout: blog title: "Kubernetes 2018 North American Contributor Summit" -date: 2018-10-16 +date: 2018-10-16 --- **Authors:** -[Bob Killen][bob] (University of Michigan) -[Sahdev Zala][sahdev] (IBM), -[Ihor Dvoretskyi][ihor] (CNCF) +[Bob Killen][bob] (University of Michigan), [Sahdev Zala][sahdev] (IBM), [Ihor Dvoretskyi][ihor] (CNCF) The 2018 North American Kubernetes Contributor Summit to be hosted right before @@ -22,32 +20,34 @@ Unlike previous Contributor Summits, the event now spans two-days with a more relaxed ‘hallway’ track and general Contributor get-together to be hosted from 5-8pm on Sunday December 9th at the [Garage Lounge and Gaming Hall][garage], just a short walk away from the Convention Center. There, contributors can enjoy -billiards, bowling, trivia and more; accompanied by a variety of food and drink. +billiards, bowling, trivia and more; accompanied by a variety of food and drink. Things pick up the following day, Monday the 10th with three separate tracks: -### New Contributor Workshop: +### New contributor workshop A half day workshop aimed at getting new and first time contributors onboarded and comfortable with working within the Kubernetes Community. Staying for the duration is required; this is not a workshop you can drop into. -### Current Contributor Track: +### Current contributor track Reserved for those that are actively engaged with the development of the project; the Current Contributor Track includes Talks, Workshops, Birds of a Feather, Unconferences, Steering Committee Sessions, and more! Keep an eye on the [schedule in GitHub][schedule] as content is frequently being updated. -### Docs Sprint: -SIG-Docs will have a curated list of issues and challenges to be tackled closer +### Docs sprint + +SIG Docs will have a curated list of issues and challenges to be tackled closer to the event date. -## To Register: +## How To Register {#to-register} + To register for the Contributor Summit, see the [Registration section of the Event Details in GitHub][register]. Please note that registrations are being reviewed. If you select the “Current Contributor Track” and are not an active contributor, you will be asked to attend the New Contributor Workshop, or asked to be put on a waitlist. With thousands of contributors and only 300 spots, we -need to make sure the right folks are in the room. +need to make sure the right folks are in the room. If you have any questions or concerns, please don’t hesitate to reach out to the Contributor Summit Events Team at community@kubernetes.io. diff --git a/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md b/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md index 37b16daf4c..6317679838 100644 --- a/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md +++ b/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md @@ -1,13 +1,12 @@ --- title: A Look Back and What's in Store for Kubernetes Contributor Summits date: 2019-03-20 +layout: blog --- **Authors:** Paris Pittman (Google), Jonas Rosland (VMware) -**tl;dr** - [click here] for Barcelona Contributor Summit information. - {{
}} As our contributing community grows in great numbers, with more than 16,000 contributors this year across 150+ GitHub repositories, it’s important to provide face to face connections for our large distributed teams to have opportunities for collaboration and learning. In [Contributor Experience], our methodology with planning events is a lot like our documentation; we build from personas -- interests, skills, and motivators to name a few. This way we ensure there is valuable content and learning for everyone. @@ -28,13 +27,14 @@ We build the contributor summits around you: These personas combined with ample feedback from previous events, produce the altogether experience that welcomed over 600 contributors in Copenhagen (May), Shanghai(November), and Seattle(December) in 2018. Seattle's event drew over 300+ contributors, equal to Shanghai and Copenhagen combined, for the 6th contributor event in Kubernetes history. In true Kubernetes fashion, we expect another record breaking year of attendance. We've pre-ordered 900+ [contributor patches], a tradition, and we are looking forward to giving them to you! -With that said... +With that said… + **Save the Dates:** Barcelona: May 19th (evening) and 20th (all day) Shanghai: June 24th (all day) San Diego: November 18th, 19th, and activities in KubeCon/CloudNativeCon week -In an effort of continual improvement, here's what to expect from us this year: +In an effort of continual improvement, here's what to expect from us this year: * Large new contributor workshops and contributor socials at all three events expected to break previous attendance records * A multiple track event in San Diego for all contributor types including workshops, birds of a feather, lightning talks and more @@ -42,7 +42,8 @@ In an effort of continual improvement, here's what to expect from us this year: * [An event website]! * Follow along with updates: kubernetes-dev@googlegroups.com is our main communication hub as always; however, we will also blog here, our [Thursday Kubernetes Community Meeting], [twitter], SIG meetings, event site, discuss.kubernetes.io, and #contributor-summit on Slack. * Opportunities to get involved: We still have 2019 roles available! -Reach out to Contributor Experience via community@kubernetes.io, stop by a Wednesday SIG update meeting, or catch us on Slack (#sig-contribex). +Reach out to Contributor Experience via community@kubernetes.io, stop by a Wednesday SIG update meeting, or catch us on Slack (#sig-contribex). + {{
}} @@ -51,11 +52,11 @@ Reach out to Contributor Experience via community@kubernetes.io, stop by a Wedne Our 2018 crew 🥁 Jorge Castro, Paris Pittman, Bob Killen, Jeff Sica, Megan Lehn, Guinevere Saenger, Josh Berkus, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Lindsey Tulloch, Zach Corleissen, Tim Pepper, Ihor Dvoretskyi, Nancy Mohamed, Chris Short, Mario Loria, Jason DeTiberus, Sahdev Zala, Mithra Raja -And an introduction to our 2019 crew (a thanks in advance ;) )... -Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles, Guinevere Saenger, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Rui Chen, Tim Pepper, Ihor Dvoretskyi, Dawn Foster +And an introduction to our 2019 crew (a thanks in advance ;) )… +Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles, Guinevere Saenger, Noah Abrahams, Yang Li, Xiangpeng Zhao, Puja Abbassi, Rui Chen, Tim Pepper, Ihor Dvoretskyi, Dawn Foster -## Relive Seattle Contributor Summit +## Relive Seattle Contributor Summit 📈 80% growth rate since the Austin 2017 December event @@ -81,15 +82,11 @@ Jonas Rosland, Josh Berkus, Paris Pittman, Jorge Castro, Bob Killen, Deb Giles, 📸 Pictures (special thanks to [rdodev]) -Garage Pic -Reg Desk - {{
}} “I love Contrib Summit! The intros and deep dives during KubeCon were a great extension of Contrib Summit. Y'all did an excellent job in the morning to level set expectations and prime everyone.” -- julianv “great work! really useful and fun!” - coffeepac -[click here]: https://events.linuxfoundation.org/events/contributor-summit-europe-2019/ [Contributor Experience]: https://github.com/kubernetes/community/tree/master/sig-contributor-experience [Subproject OWNERs]: https://github.com/kubernetes/community/blob/master/community-membership.md [Chair or Tech Lead]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md diff --git a/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md b/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md index 41c5fbcf36..a394e0a90f 100644 --- a/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md +++ b/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md @@ -36,4 +36,4 @@ To make this all possible, we need you. Yes, you, to register. As much as we lov We look forward to seeing you! -_Special thanks to [Leah Petersen](https://www.linkedin.com/in/leahstunts/), [Sarah Conway](https://www.linkedin.com/in/sarah-conway-6166151/) and [Paris Pittman](https://www.linkedin.com/in/parispittman/) for their help in editing this post._ +_Special thanks to [Leah Petersen](https://www.linkedin.com/in/leahstunts/), [Sarah Conway](https://www.linkedin.com/in/sarah-conway-6166151/) and [Paris Pittman](https://www.linkedin.com/in/parispittman/) for their help in editing this post._ diff --git a/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md b/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md index 350fbb1735..7bedde5ec6 100644 --- a/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md +++ b/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md @@ -5,17 +5,15 @@ date: 2019-09-24 slug: san-diego-contributor-summit --- -**Authors: Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware)** - - +**Authors:** Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware) [Contributor Summit San Diego 2019 Event Page] -Registration is now open and in record time, we’ve hit capacity for the -*new contributor workshop* session of the event! Waitlist is now available. +In record time, we’ve hit capacity for the *new contributor workshop* session of +the event! **Sunday, November 17** Evening Contributor Celebration: -[QuartYard]* +[QuartYard]† Address: 1301 Market Street, San Diego, CA 92101 Time: 6:00PM - 9:00PM @@ -68,7 +66,7 @@ Check out past blogs on [persona building around our events] and the [Barcelona ![Group Picture in 2018](/images/blog/2019-09-24-san-diego-contributor-summit/IMG_2588.JPG) -*=QuartYard has a huge stage! Want to perform something in front of your contributor peers? Reach out to us! community@kubernetes.io +†=QuartYard has a huge stage! Want to perform something in front of your contributor peers? Reach out to us! community@kubernetes.io diff --git a/content/en/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md b/content/en/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md index e78b6a0ec7..f0f2835513 100644 --- a/content/en/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md +++ b/content/en/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md @@ -5,13 +5,7 @@ date: 2019-10-10 slug: contributor-summit-san-diego-schedule --- - -Authors: Josh Berkus (Red Hat), Paris Pittman (Google), Jonas Rosland (VMware) - -tl;dr A week ago we announced that [registration is open][reg] for the contributor -summit , and we're now live with [the full Contributor Summit schedule!][schedule] -Grab your spot while tickets are still available. There is currently a waitlist -for new contributor workshop. ([Register here!][reg]) +**Authors:** Josh Berkus (Red Hat), Paris Pittman (Google), Jonas Rosland (VMware) There are many great sessions planned for the Contributor Summit, spread across five rooms of current contributor content in addition to the new contributor @@ -32,7 +26,7 @@ While the schedule contains difficult decisions in every timeslot, we've picked a few below to give you a taste of what you'll hear, see, and participate in, at the summit: -* **[Vision]**: SIG-Architecture will be sharing their vision of where we're going +* **[Vision]**: SIG Architecture will be sharing their vision of where we're going with Kubernetes development for the next year and beyond. * **[Security]**: Tim Allclair and CJ Cullen will present on the current state of Kubernetes security. In another security talk, Vallery Lancey will lead a @@ -47,7 +41,7 @@ the summit: one, or at least pass one. * **[End Users]**: Several end users from the CNCF partner ecosystem, invited by Cheryl Hung, will hold a Q&A with contributors to strengthen our feedback loop. -* **[Docs]**: As always, SIG-Docs will run a three-hour contributing-to-documentation +* **[Docs]**: As always, SIG Docs will run a three-hour contributing-to-documentation workshop. We're also giving out awards to contributors who distinguished themselves in 2019, diff --git a/content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md b/content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md index ae05bd8b9c..11e3ccc412 100644 --- a/content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md +++ b/content/en/blog/_posts/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced.md @@ -5,11 +5,28 @@ date: 2020-02-18 slug: Contributor-Summit-Amsterdam-Schedule-Announced --- -**Authors:** Jeffrey Sica (Red Hat), Amanda Katona (VMware) +**Authors:** Jeffrey Sica (Red Hat), Amanda Katona (VMware) -tl;dr [Registration is open](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/) and the [schedule is live](https://kcseu2020.sched.com/) so register now and we’ll see you in Amsterdam! +![Contributor Summit](/images/blog/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced/contribsummit.jpg) -## Kubernetes Contributor Summit +Hello everyone and Happy 2020! It’s hard to believe that KubeCon EU 2020 is less than six weeks away, and with that another contributor summit! This year we have the pleasure of being in Amsterdam in early spring, so be sure to pack some warmer clothing. This summit looks to be exciting with a lot of fantastic community-driven content. We received **26** submissions from the CFP. From that, the events team selected **12** sessions. Each of the sessions falls into one of four categories: + +* Community +* Contributor Improvement +* Sustainability +* In-depth Technical + +On top of the presentations, there will be a dedicated Docs Sprint as well as the New Contributor Workshop 101 and 201 Sessions. All told, we will have five separate rooms of content throughout the day on Monday. Please **[see the full schedule](https://kcseu2020.sched.com/)** to see what sessions you’d be interested in. We hope between the content provided and the inevitable hallway track, everyone has a fun and enriching experience. + +Speaking of fun, the social Sunday night should be a blast! We’re hosting this summit’s social close to the conference center, at [ZuidPool](https://www.zuid-pool.nl/en/). There will be games, bingo, and unconference sign-up throughout the evening. It should be a relaxed way to kick off the week. + +[~Registration is open~](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/)! Space is limited so it’s always a good idea to register early. + +If you have any questions, reach out to the [Amsterdam Team](https://github.com/kubernetes/community/tree/master/events/2020/03-contributor-summit#team) on Slack in the [#contributor-summit](https://kubernetes.slack.com/archives/C7J893413) channel. + +Hope to see you there! + +## Kubernetes Contributor Summit schedule **Sunday, March 29, 2020** @@ -25,21 +42,3 @@ tl;dr [Registration is open](https://events.linuxfoundation.org/kubernetes-contr - Address: [Europaplein 24, 1078 GZ Amsterdam, Netherlands](https://www.google.com/search?q=kubecon+amsterdam+2020&oq=kubecon+amste&aqs=chrome.0.35i39j69i57j0l4j69i61l2.3957j1j4&sourceid=chrome&ie=UTF-8&ibp=htl;events&rciv=evn&sa=X&ved=2ahUKEwiZoLvQ0dvnAhVST6wKHScBBZ8Q5bwDMAB6BAgSEAE#) - Time: 09:00 - 17:00 (Breakfast at 08:00) -![Contributor Summit](/images/blog/2020-02-18-Contributor-Summit-Amsterdam-Schedule-Announced/contribsummit.jpg) - -Hello everyone and Happy 2020! It’s hard to believe that KubeCon EU 2020 is less than six weeks away, and with that another contributor summit! This year we have the pleasure of being in Amsterdam in early spring, so be sure to pack some warmer clothing. This summit looks to be exciting with a lot of fantastic community-driven content. We received **26** submissions from the CFP. From that, the events team selected **12** sessions. Each of the sessions falls into one of four categories: - -* Community -* Contributor Improvement -* Sustainability -* In-depth Technical - -On top of the presentations, there will be a dedicated Docs Sprint as well as the New Contributor Workshop 101 and 201 Sessions. All told, we will have five separate rooms of content throughout the day on Monday. Please **[see the full schedule](https://kcseu2020.sched.com/)** to see what sessions you’d be interested in. We hope between the content provided and the inevitable hallway track, everyone has a fun and enriching experience. - -Speaking of fun, the social Sunday night should be a blast! We’re hosting this summit’s social close to the conference center, at [ZuidPool](https://www.zuid-pool.nl/en/). There will be games, bingo, and unconference sign-up throughout the evening. It should be a relaxed way to kick off the week. - -[Registration is open](https://events.linuxfoundation.org/kubernetes-contributor-summit-europe/)! Space is limited so it’s always a good idea to register early. - -If you have any questions, reach out to the [Amsterdam Team](https://github.com/kubernetes/community/tree/master/events/2020/03-contributor-summit#team) on Slack in the [#contributor-summit](https://kubernetes.slack.com/archives/C7J893413) channel. - -Hope to see you there! diff --git a/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md b/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md index 1996b6201e..ff687eb040 100644 --- a/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md +++ b/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md @@ -5,11 +5,11 @@ date: 2020-03-04 slug: Contributor-Summit-Delayed --- -**Authors:** Dawn Foster (VMware), Jorge Castro (VMware) +**Authors:** Dawn Foster (VMware), Jorge Castro (VMware) The CNCF has announced that [KubeCon + CloudNativeCon EU has been delayed](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/) until July/August of 2020. As a result the Contributor Summit planning team is weighing options for how to proceed. Here’s the current plan: - There will be an in-person Contributor Summit as planned when KubeCon + CloudNativeCon is rescheduled. -- We are looking at options for having additional virtual contributor activities in the meantime. +- We are looking at options for having additional virtual contributor activities in the meantime. We will communicate via this blog and the usual communications channels on the final plan. Please bear with us as we adapt when we get more information. Thank you for being patient as the team pivots to bring you a great Contributor Summit! \ No newline at end of file From a37f7c7d0c52cfa97d2e3f7843c569f879707ac8 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 21 Mar 2022 23:02:24 +0000 Subject: [PATCH 057/827] Mark article non-evergreen Explicitly mark some stale content. --- .../blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md b/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md index a394e0a90f..bf8417673b 100644 --- a/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md +++ b/content/en/blog/_posts/2019-05-02-kubecon-diversity-lunch-and-hack.md @@ -2,6 +2,7 @@ title: "Join us for the 2019 KubeCon Diversity Lunch & Hack" date: 2019-05-02 slug: kubecon-diversity-lunch-and-hack +evergreen: false --- **Authors:** Kiran Oliver, Podcast Producer, The New Stack From 1a023202ff198a264ee4c795c588d6bce9abbeb2 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 21 Mar 2022 23:03:01 +0000 Subject: [PATCH 058/827] Mark evergreen articles as such MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This change hides the “outdated content” banner at the top of the marked pages. --- content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md | 1 + content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md | 1 + content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md | 1 + ...formance-Upgrades-Improved-Tooling-And-A-Growing-Community.md | 1 + .../_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md | 1 + ...pgrades-Plus-Easier-Application-Deployment-And-Management-.md | 1 + ...ernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md | 1 + .../_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md | 1 + .../2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md | 1 + ...26-kubernetes-1-10-stabilizing-storage-security-networking.md | 1 + .../_posts/2018-06-26-kubernetes-1-11-release-announcement.md | 1 + .../_posts/2018-09-27-kubernetes-1-12-release-announcement.md | 1 + ...18-10-16-kubernetes-2018-north-american-contributor-summit.md | 1 + .../_posts/2018-12-03-kubernetes-1-13-release-announcement.md | 1 + content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md | 1 + ...Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md | 1 + content/en/blog/_posts/2019-03-25-1-14-release-announcement.md | 1 + .../_posts/2019-06-19-kubernetes-1-15-release-announcement.md | 1 + .../en/blog/_posts/2019-09-24-san-diego-contributor-summit.md | 1 + content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md | 1 + 20 files changed, 20 insertions(+) diff --git a/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md b/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md index 6acce95939..45502e0072 100644 --- a/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md +++ b/content/en/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md @@ -3,6 +3,7 @@ title: Welcome to the Kubernetes Blog! date: 2015-03-20 slug: welcome-to-kubernetes-blog url: /blog/2015/03/Welcome-To-Kubernetes-Blog +evergreen: true --- **Author:** Kit Merker (Google) diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md index e070945501..86dcc36bb9 100644 --- a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md +++ b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0160.md @@ -3,6 +3,7 @@ title: "Kubernetes Release: 0.16.0" date: 2015-05-11 slug: kubernetes-release-0160 url: /blog/2015/05/Kubernetes-Release-0160 +evergreen: true --- Release Notes: diff --git a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md index c326392c95..0859edc059 100644 --- a/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md +++ b/content/en/blog/_posts/2015-05-00-Kubernetes-Release-0170.md @@ -3,6 +3,7 @@ title: "Kubernetes Release: 0.17.0" date: 2015-05-15 slug: kubernetes-release-0170 url: /blog/2015/05/Kubernetes-Release-0170 +evergreen: true --- Release Notes: diff --git a/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md b/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md index 5e433c180b..953504df01 100644 --- a/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md +++ b/content/en/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md @@ -3,6 +3,7 @@ title: "Kubernetes 1.1 Performance upgrades, improved tooling and a growing comm date: 2015-11-09 slug: kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community url: /blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community +evergreen: true --- **Author:** David Aronchick (Google) diff --git a/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md b/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md index 9150ae36e6..c0995e1c14 100644 --- a/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md +++ b/content/en/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md @@ -3,6 +3,7 @@ title: "KubeCon EU 2016: Kubernetes Community in London" date: 2016-02-24 slug: kubecon-eu-2016-kubernetes-community-in url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In +evergreen: true --- **Author:** Sarah Novotny (Google) diff --git a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md index de05def28e..bc9083bc0d 100644 --- a/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md +++ b/content/en/blog/_posts/2016-03-00-Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management-.md @@ -3,6 +3,7 @@ title: "Kubernetes 1.2: Even more performance upgrades, plus easier application date: 2016-03-17 slug: kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management url: /blog/2016/03/Kubernetes-1-2-Even-More-Performance-Upgrades-Plus-Easier-Application-Deployment-And-Management +evergreen: true --- **Author:** David Aronchick (Google) diff --git a/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md index 74f9a41db1..bc86fa5eeb 100644 --- a/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md +++ b/content/en/blog/_posts/2016-07-00-Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads.md @@ -3,6 +3,7 @@ title: "Kubernetes 1.3: Bridging Cloud Native and Enterprise Workloads" date: 2016-07-06 slug: kubernetes-1.3-bridging-cloud-native-and-enterprise-workloads url: /blog/2016/07/Kubernetes-1-3-Bridging-Cloud-Native-And-Enterprise-Workloads +evergreen: true --- **Author:** Aparna Sinha, Google diff --git a/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md b/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md index 00ed354d86..e2f031f8a5 100644 --- a/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md +++ b/content/en/blog/_posts/2017-09-00-Kubernetes-18-Security-Workloads-And.md @@ -3,6 +3,7 @@ title: " Kubernetes 1.8: Security, Workloads and Feature Depth " date: 2017-09-29 slug: kubernetes-18-security-workloads-and url: /blog/2017/09/Kubernetes-18-Security-Workloads-And +evergreen: true --- **Authors:** Kubernetes v1.8 release team diff --git a/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md b/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md index 8f3671300b..cefcf21452 100644 --- a/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md +++ b/content/en/blog/_posts/2017-12-00-Kubernetes-19-Workloads-Expanded-Ecosystem.md @@ -3,6 +3,7 @@ title: "Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem" date: 2017-12-15 slug: kubernetes-19-workloads-expanded-ecosystem url: /blog/2017/12/Kubernetes-19-Workloads-Expanded-Ecosystem +evergreen: true --- **Authors:** Kubernetes v1.9 release team diff --git a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md index a802e6f20c..904b2d34e9 100644 --- a/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md +++ b/content/en/blog/_posts/2018-03-26-kubernetes-1-10-stabilizing-storage-security-networking.md @@ -3,6 +3,7 @@ title: 'Kubernetes 1.10: Stabilizing Storage, Security, and Networking' date: 2018-03-26 modified_time: '2018-03-27T11:01:39.569-07:00' slug: kubernetes-1.10-stabilizing-storage-security-networking +evergreen: true --- ***Editor's note: today's post is by the [1.10 Release diff --git a/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md index a5d9f8b4d0..4d3007f290 100644 --- a/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md +++ b/content/en/blog/_posts/2018-06-26-kubernetes-1-11-release-announcement.md @@ -3,6 +3,7 @@ layout: blog title: 'Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability' date: 2018-06-27 slug: kubernetes-1.11-release-announcement +evergreen: true --- **Author**: Kubernetes 1.11 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.11/release_team.md) diff --git a/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md b/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md index b24a6cbe09..1f847a38ca 100644 --- a/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md +++ b/content/en/blog/_posts/2018-09-27-kubernetes-1-12-release-announcement.md @@ -2,6 +2,7 @@ layout: blog title: 'Kubernetes 1.12: Kubelet TLS Bootstrap and Azure Virtual Machine Scale Sets (VMSS) Move to General Availability' date: 2018-09-27 +evergreen: true --- **Author**: The 1.12 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.12/release_team.md) diff --git a/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md b/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md index 53846e6cee..13158529a2 100644 --- a/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md +++ b/content/en/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md @@ -2,6 +2,7 @@ layout: blog title: "Kubernetes 2018 North American Contributor Summit" date: 2018-10-16 +evergreen: true --- **Authors:** diff --git a/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md b/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md index 8aba0dc232..3e76486764 100644 --- a/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md +++ b/content/en/blog/_posts/2018-12-03-kubernetes-1-13-release-announcement.md @@ -3,6 +3,7 @@ layout: blog title: 'Kubernetes 1.13: Simplified Cluster Management with Kubeadm, Container Storage Interface (CSI), and CoreDNS as Default DNS are Now Generally Available' date: 2018-12-03 slug: kubernetes-1-13-release-announcement +evergreen: true --- **Author**: The 1.13 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.13/release_team.md) diff --git a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md index 8601a7b94d..7ce4106076 100644 --- a/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md +++ b/content/en/blog/_posts/2018-12-04-kubeadm-ga-release.md @@ -2,6 +2,7 @@ layout: blog title: Production-Ready Kubernetes Cluster Creation with kubeadm date: 2018-12-04 +evergreen: true --- **Authors**: Lucas Käldström (CNCF Ambassador) and Luc Perkins (CNCF Developer Advocate) diff --git a/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md b/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md index 6317679838..99a8dcd886 100644 --- a/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md +++ b/content/en/blog/_posts/2019-03-20-A-Look-Back-And-Whats-In-Store-For-Kubernetes-Contributor-Summits.md @@ -2,6 +2,7 @@ title: A Look Back and What's in Store for Kubernetes Contributor Summits date: 2019-03-20 layout: blog +evergreen: true --- **Authors:** diff --git a/content/en/blog/_posts/2019-03-25-1-14-release-announcement.md b/content/en/blog/_posts/2019-03-25-1-14-release-announcement.md index 448309ba3a..e021bbf1db 100644 --- a/content/en/blog/_posts/2019-03-25-1-14-release-announcement.md +++ b/content/en/blog/_posts/2019-03-25-1-14-release-announcement.md @@ -2,6 +2,7 @@ title: 'Kubernetes 1.14: Production-level support for Windows Nodes, Kubectl Updates, Persistent Local Volumes GA' date: 2019-03-25 slug: kubernetes-1-14-release-announcement +evergreen: true --- **Authors:** The 1.14 [Release Team](https://bit.ly/k8s114-team) diff --git a/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md b/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md index 3561203548..83dfb6dd50 100644 --- a/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md +++ b/content/en/blog/_posts/2019-06-19-kubernetes-1-15-release-announcement.md @@ -3,6 +3,7 @@ layout: blog title: "Kubernetes 1.15: Extensibility and Continuous Improvement" date: 2019-06-19 slug: kubernetes-1-15-release-announcement +evergreen: true --- **Authors:** The 1.15 [Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.15/release_team.md) diff --git a/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md b/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md index 7bedde5ec6..62ea9c8337 100644 --- a/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md +++ b/content/en/blog/_posts/2019-09-24-san-diego-contributor-summit.md @@ -3,6 +3,7 @@ layout: blog title: "Contributor Summit San Diego Registration Open!" date: 2019-09-24 slug: san-diego-contributor-summit +evergreen: true --- **Authors:** Paris Pittman (Google), Jeffrey Sica (Red Hat), Jonas Rosland (VMware) diff --git a/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md b/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md index ff687eb040..10d96ec351 100644 --- a/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md +++ b/content/en/blog/_posts/2020-03-04-Contributor-Summit-Delayed.md @@ -3,6 +3,7 @@ layout: blog title: Contributor Summit Amsterdam Postponed date: 2020-03-04 slug: Contributor-Summit-Delayed +evergreen: true --- **Authors:** Dawn Foster (VMware), Jorge Castro (VMware) From 7cdbb1f3c45d6bf88b2ce363d5f51710cdf99542 Mon Sep 17 00:00:00 2001 From: xing-yang Date: Wed, 25 May 2022 19:19:01 +0000 Subject: [PATCH 059/827] Address comments --- .../custom-resource-definition-versioning.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 28757ffd84..730a0fd688 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -355,11 +355,8 @@ spec: ### Version removal -An API version can be removed if there is a newer API version served and stored in the API server for at least 3 Kubernetes releases. -The older API version cannot be dropped from the CRD manifest until data has been migrated to the newer API version for all clusters that served the older version of the CRD and cleared the older version from status.storedVersions. +An older API version cannot be dropped from a CustomResourceDefinition manifest until existing persisted data has been migrated to the newer API version for all clusters that served the older version of the custom resource, and the old version is removed from the `status.storedVersions` of the CustomResourceDefinition. -{{< tabs name="CustomResourceDefinition_versioning_removal" >}} -{{% tab name="apiextensions.k8s.io/v1" %}} ```yaml apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition @@ -373,12 +370,13 @@ spec: scope: Namespaced versions: - name: v1beta1 - served: false # This indicates the v1beta1 version of the custom resource is no longer served. # API requests to this version receive a not found error in the server response. + served: false schema: ... - name: v1 served: true + # The new served version should be set as the storage version storage: true schema: ... ``` From db056570a9f589b2a4f2a56ff11064ae3d6688fd Mon Sep 17 00:00:00 2001 From: Shannon Kularathna Date: Sat, 5 Mar 2022 11:29:44 -0500 Subject: [PATCH 060/827] Remove 'Legacy Docker integration' from cAdvisor sentence Co-authored-by: Tim Bannister --- .../tasks/debug/debug-cluster/resource-usage-monitoring.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md b/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md index b02d6ab31a..3c270b8122 100644 --- a/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md +++ b/content/en/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md @@ -41,8 +41,11 @@ memory usage. The kubelet acts as a bridge between the Kubernetes master and the nodes, managing the pods and containers running on a machine. The kubelet translates each pod into its constituent containers and fetches individual container usage statistics from the container runtime through the container -runtime interface. The kubelet fetches this information from the integrated -cAdvisor for the legacy Docker integration. It then exposes the aggregated pod +runtime interface. If you use a container runtime that uses Linux cgroups and +namespaces to implement containers, and the container runtime does not publish +usage statistics, then the kubelet can look up those statistics directly +(using code from [cAdvisor](https://github.com/google/cadvisor)). +No matter how those statistics arrive, the kubelet then exposes the aggregated pod resource usage statistics through the metrics-server Resource Metrics API. This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and read-only ports. From 7f3604a949c1d85b2074cea3e3068e1b522850d8 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Mon, 21 Mar 2022 22:29:53 +0000 Subject: [PATCH 061/827] Revise downward API documentation - add a glossary entry - add a concept page - revise other documentation in light of above changes --- content/en/docs/concepts/storage/volumes.md | 12 +- .../concepts/workloads/pods/downward-api.md | 131 ++++++++++++++++ .../docs/reference/glossary/downward-api.md | 28 ++++ ...nward-api-volume-expose-pod-information.md | 145 ++++++------------ ...ronment-variable-expose-pod-information.md | 89 ++++++----- 5 files changed, 255 insertions(+), 150 deletions(-) create mode 100644 content/en/docs/concepts/workloads/pods/downward-api.md create mode 100644 content/en/docs/reference/glossary/downward-api.md diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index cc9a9565eb..372c8082c1 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -295,15 +295,17 @@ keyed with `log_level`. ### downwardAPI {#downwardapi} -A `downwardAPI` volume makes downward API data available to applications. -It mounts a directory and writes the requested data in plain text files. +A `downwardAPI` volume makes {{< glossary_tooltip term_id="downward-api" text="downward API" >}} +data available to applications. Within the volume, you can find the exposed +data as read-only files in plain text format. {{< note >}} -A container using the downward API as a [`subPath`](#using-subpath) volume mount will not -receive downward API updates. +A container using the downward API as a [`subPath`](#using-subpath) volume mount does not +receive updates when field values change. {{< /note >}} -See the [downward API example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) for more details. +See [Expose Pod Information to Containers Through Files](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +to learn more. ### emptyDir {#emptydir} diff --git a/content/en/docs/concepts/workloads/pods/downward-api.md b/content/en/docs/concepts/workloads/pods/downward-api.md new file mode 100644 index 0000000000..40b2362959 --- /dev/null +++ b/content/en/docs/concepts/workloads/pods/downward-api.md @@ -0,0 +1,131 @@ +--- +title: Downward API +content_type: concept +description: > + There are two ways to expose Pod and container fields to a running container: + environment variables, and as files that are populated by a special volume type. + Together, these two ways of exposing Pod and container fields are called the downward API. +--- + + + +It is sometimes useful for a container to have information about itself, without +being overly coupled to Kubernetes. The _downward API_ allows containers to consume +information about themselves or the cluster without using the Kubernetes client +or API server. + +An example is an existing application that assumes a particular well-known +environment variable holds a unique identifier. One possibility is to wrap the +application, but that is tedious and error prone, and it violates the goal of low +coupling. A better option would be to use the Pod's name as an identifier, and +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 [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 +_downward API_. + + + +## Available fields + +Only some Kubernetes API fields are available through the downward API. This +section lists which fields you can make available. + +You can pass information from available Pod-level fields using `fieldRef`. +At the API level, the `spec` for a Pod always defines at least one +[Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container). +You can pass information from available Container-level fields using +`resourceFieldRef`. + +### Information available via `fieldRef` {#downwardapi-fieldRef} + +For most Pod-level fields, you can provide them to a container either as +an environment variable or using a `downwardAPI` volume. The fields available +via either mechanism are: + +`metadata.name` +: the pod's name + +`metadata.namespace` +: the pod's {{< glossary_tooltip text="namespace" term_id="namespace" >}} + +`metadata.uid` +: the pod's unique ID + +`metadata.annotations['']` +: the value of the pod's {{< glossary_tooltip text="annotation" term_id="annotation" >}} named `` (for example, `metadata.annotations['myannotation']`) + +`metadata.labels['']` +: the text value of the pod's {{< glossary_tooltip text="label" term_id="label" >}} named `` (for example, `metadata.labels['mylabel']`) + +`spec.serviceAccountName` +: the name of the pod's {{< glossary_tooltip text="service account" term_id="service-account" >}} + +`spec.nodeName` +: the name of the {{< glossary_tooltip term_id="node" text="node">}} where the Pod is executing + +`status.hostIP` +: the primary IP address of the node to which the Pod is assigned + +`status.podIP` +: the pod's primary IP address (usually, its IPv4 address) + +In addition, the following information is available through +a `downwardAPI` volume `fieldRef`, but **not as environment variables**: + +`metadata.labels` +: all of the pod's labels, formatted as `label-key="escaped-label-value"` with one label per line + +`metadata.annotations` +: all of the pod's annotations, formatted as `annotation-key="escaped-annotation-value"` with one annotation per line + +### Information available via `resourceFieldRef` {#downwardapi-resourceFieldRef} + +These container-level fields allow you to provide information about +[requests and limits](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) +for resources such as CPU and memory. + + +`resource: limits.cpu` +: A container's CPU limit + +`resource: requests.cpu` +: A container's CPU request + +`resource: limits.memory` +: A container's memory limit + +`resource: requests.memory` +: A container's memory request + +`resource: limits.hugepages-*` +: A container's hugepages limit (provided that the `DownwardAPIHugePages` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled) + +`resource: requests.hugepages-*` +: A container's hugepages request (provided that the `DownwardAPIHugePages` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled) + +`resource: limits.ephemeral-storage` +: A container's ephemeral-storage limit + +`resource: requests.ephemeral-storage` +: A container's ephemeral-storage request + +#### Fallback information for resource limits + +If CPU and memory limits are not specified for a container, and you use the +downward API to try to expose that information, then the +kubelet defaults to exposing the maximum allocatable value for CPU and memory +(based on the [node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +calculation). + +## {{% heading "whatsnext" %}} + +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 [files in `downwardAPI` volume](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) diff --git a/content/en/docs/reference/glossary/downward-api.md b/content/en/docs/reference/glossary/downward-api.md new file mode 100644 index 0000000000..a3d9a46336 --- /dev/null +++ b/content/en/docs/reference/glossary/downward-api.md @@ -0,0 +1,28 @@ +--- +title: Downward API +id: downward-api +date: 2022-03-21 +short_description: > + A mechanism to expose Pod and container field values to code running in a container. +aka: +full_link: /docs/concepts/workloads/pods/downward-api/ +tags: +- architecture +--- +Kubernetes' mechanism to expose Pod and container field values to code running in a container. + +It is sometimes useful for a container to have information about itself, without +needing to make changes to the container code that directly couple it to Kubernetes. + +The Kubernetes downward API allows containers to consume information about themselves +or their context in a Kubernetes cluster. Applications in containers can have +access to that information, without the application needing to act as a client of +the Kubernetes API. + +There are two ways to expose Pod and container fields to a running container: + +- using [environment variables](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +- using [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 _downward API_. + diff --git a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index e9f5f1fb3e..ae36e9bc1c 100644 --- a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -7,38 +7,38 @@ weight: 40 This page shows how a Pod can use a -[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core) -to expose information about itself to Containers running in the Pod. -A `DownwardAPIVolumeFile` can expose Pod fields and Container fields. +[`downwardAPI` volume](/docs/concepts/storage/volumes/#downwardapi), +to expose information about itself to containers running in the Pod. +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) +* Volume files, as explained in this task + +Together, these two ways of exposing Pod and container fields are called the +_downward API_. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + -## The Downward API - -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) -* Volume files - -Together, these two ways of exposing Pod and Container fields are called the -"Downward API". - ## Store Pod fields -In this exercise, you create a Pod that has one Container. -Here is the configuration file for the Pod: +In this part of exercise, you create a Pod that has one container, and you +project Pod-level fields into the running container as files. +Here is the manifest for the Pod: {{< codenew file="pods/inject/dapi-volume.yaml" >}} -In the configuration file, you can see that the Pod has a `downwardAPI` Volume, -and the Container mounts the Volume at `/etc/podinfo`. +In the manifest, you can see that the Pod has a `downwardAPI` Volume, +and the container mounts the volume at `/etc/podinfo`. -Look at the `items` array under `downwardAPI`. Each element of the array is a -[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core). +Look at the `items` array under `downwardAPI`. Each element of the array +defines a `downwardAPI` volume. The first element specifies that the value of the Pod's `metadata.labels` field should be stored in a file named `labels`. The second element specifies that the value of the Pod's `annotations` @@ -46,7 +46,7 @@ field should be stored in a file named `annotations`. {{< note >}} The fields in this example are Pod fields. They are not -fields of the Container in the Pod. +fields of the container in the Pod. {{< /note >}} Create the Pod: @@ -145,26 +145,30 @@ Exit the shell: /# exit ``` -## Store Container fields +## Store container fields -The preceding exercise, you stored Pod fields in a -[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core).. -In this next exercise, you store Container fields. Here is the configuration -file for a Pod that has one Container: +The preceding exercise, you made Pod-level fields accessible using the +downward API. +In this next exercise, you are going to pass fields that are part of the Pod +definition, but taken from the specific +[container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) +rather than from the Pod overall. Here is a manifest for a Pod that again has +just one container: {{< codenew file="pods/inject/dapi-volume-resources.yaml" >}} -In the configuration file, you can see that the Pod has a +In the manifest, you can see that the Pod has a [`downwardAPI` volume](/docs/concepts/storage/volumes/#downwardapi), -and the Container mounts the volume at `/etc/podinfo`. +and that the single container in that Pod mounts the volume at `/etc/podinfo`. -Look at the `items` array under `downwardAPI`. Each element of the array is a -[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core). +Look at the `items` array under `downwardAPI`. Each element of the array +defines a file in the downward API volume. -The first element specifies that in the Container named `client-container`, +The first element specifies that in the container named `client-container`, the value of the `limits.cpu` field in the format specified by `1m` should be -stored in a file named `cpu_limit`. The `divisor` field is optional and has the -default value of `1` which means cores for cpu and bytes for memory. +published as a file named `cpu_limit`. The `divisor` field is optional and has the +default value of `1`. A divisor of 1 means cores for `cpu` resources, or +bytes for `memory` resources. Create the Pod: @@ -181,7 +185,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh In your shell, view the `cpu_limit` file: ```shell -/# cat /etc/podinfo/cpu_limit +# Run this in a shell inside the container +cat /etc/podinfo/cpu_limit ``` You can use similar commands to view the `cpu_request`, `mem_limit` and @@ -189,79 +194,20 @@ You can use similar commands to view the `cpu_request`, `mem_limit` and - -## Capabilities of the Downward API - -The following information is available to containers through environment -variables and `downwardAPI` volumes: - -* Information available via `fieldRef`: - - * `metadata.name` - the pod's name - * `metadata.namespace` - the pod's namespace - * `metadata.uid` - the pod's UID - * `metadata.labels['']` - the value of the pod's label `` - (for example, `metadata.labels['mylabel']`) - * `metadata.annotations['']` - the value of the pod's annotation `` - (for example, `metadata.annotations['myannotation']`) - -* Information available via `resourceFieldRef`: - - * A Container's CPU limit - * A Container's CPU request - * A Container's memory limit - * A Container's memory request - * A Container's hugepages limit (provided that the `DownwardAPIHugePages` - [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled) - * A Container's hugepages request (provided that the `DownwardAPIHugePages` - [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled) - * A Container's ephemeral-storage limit - * A Container's ephemeral-storage request - -In addition, the following information is available through -`downwardAPI` volume `fieldRef`: - -* `metadata.labels` - all of the pod's labels, formatted as `label-key="escaped-label-value"` - with one label per line -* `metadata.annotations` - all of the pod's annotations, formatted as - `annotation-key="escaped-annotation-value"` with one annotation per line - -The following information is available through environment variables: - -* `status.podIP` - the pod's IP address -* `spec.serviceAccountName` - the pod's service account name -* `spec.nodeName` - the name of the node to which the scheduler always attempts to - schedule the pod -* `status.hostIP` - the IP of the node to which the Pod is assigned - -{{< note >}} -If CPU and memory limits are not specified for a Container, the -Downward API defaults to the node allocatable value for CPU and memory. -{{< /note >}} - ## Project keys to specific paths and file permissions You can project keys to specific paths and specific permissions on a per-file basis. For more information, see [Secrets](/docs/concepts/configuration/secret/). -## Motivation for the Downward API - -It is sometimes useful for a container to have information about itself, without -being overly coupled to Kubernetes. The Downward API allows containers to consume -information about themselves or the cluster without using the Kubernetes client -or API server. - -An example is an existing application that assumes a particular well-known -environment variable holds a unique identifier. One possibility is to wrap the -application, but that is tedious and error prone, and it violates the goal of low -coupling. A better option would be to use the Pod's name as an identifier, and -inject the Pod's name into the well-known environment variable. - ## {{% heading "whatsnext" %}} -* Check the [`PodSpec`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) - API definition which defines the desired state of a Pod. +* Read the [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) + API definition for Pod. This includes the definition of Container (part of Pod). +* Read the list of [available fields](/docs/concepts/workloads/pods/downward-api/#available-fields) that you + can expose using the downward API. + +Read about volumes in the legacy API reference: * Check the [`Volume`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) API definition which defines a generic volume in a Pod for containers to access. * Check the [`DownwardAPIVolumeSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core) @@ -271,4 +217,3 @@ inject the Pod's name into the well-known environment variable. populating a file in the Downward API volume. * Check the [`ResourceFieldSelector`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) API definition which specifies the container resources and their output format. - diff --git a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md index 2b59921c6e..163b3498dc 100644 --- a/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md +++ b/content/en/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -7,50 +7,40 @@ weight: 30 This page shows how a Pod can use environment variables to expose information -about itself to Containers running in the Pod. Environment variables can expose -Pod fields and Container fields. +about itself to containers running in the Pod, using the _downward API_. +You can use environment variables to expose Pod fields, container fields, or both. +In Kubernetes, there are two ways to expose Pod and container fields to a running container: +* _Environment variables_, as explained in this task +* [Volume files](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +Together, these two ways of exposing Pod and container fields are called the +downward API. ## {{% heading "prerequisites" %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - +{{< include "task-tutorial-prereqs.md" >}} -## The Downward API - -There are two ways to expose Pod and Container fields to a running Container: - -* Environment variables -* [Volume Files](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) - -Together, these two ways of exposing Pod and Container fields are called the -*Downward API*. - - ## Use Pod fields as values for environment variables -In this exercise, you create a Pod that has one Container. Here is the -configuration file for the Pod: +In this part of exercise, you create a Pod that has one container, and you +project Pod-level fields into the running container as environment variables. {{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} -In the configuration file, you can see five environment variables. The `env` +In that manifest, you can see five environment variables. The `env` field is an array of -[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core). +environment variable definitions. The first element in the array specifies that the `MY_NODE_NAME` environment variable gets its value from the Pod's `spec.nodeName` field. Similarly, the other environment variables get their names from Pod fields. {{< note >}} The fields in this example are Pod fields. They are not fields of the -Container in the Pod. +container in the Pod. {{< /note >}} Create the Pod: @@ -59,13 +49,14 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml ``` -Verify that the Container in the Pod is running: +Verify that the container in the Pod is running: ```shell +# If the new Pod isn't yet healthy, rerun this command a few times. kubectl get pods ``` -View the Container's logs: +View the container's logs: ```shell kubectl logs dapi-envars-fieldref @@ -82,10 +73,10 @@ default ``` To see why these values are in the log, look at the `command` and `args` fields -in the configuration file. When the Container starts, it writes the values of +in the configuration file. When the container starts, it writes the values of five environment variables to stdout. It repeats this every ten seconds. -Next, get a shell into the Container that is running in your Pod: +Next, get a shell into the container that is running in your Pod: ```shell kubectl exec -it dapi-envars-fieldref -- sh @@ -94,7 +85,8 @@ kubectl exec -it dapi-envars-fieldref -- sh In your shell, view the environment variables: ```shell -/# printenv +# Run this in a shell inside the container +printenv ``` The output shows that certain environment variables have been assigned the @@ -111,22 +103,26 @@ MY_NODE_NAME=minikube MY_POD_NAME=dapi-envars-fieldref ``` -## Use Container fields as values for environment variables +## Use container fields as values for environment variables -In the preceding exercise, you used Pod fields as the values for environment -variables. In this next exercise, you use Container fields as the values for -environment variables. Here is the configuration file for a Pod that has one -container: +In the preceding exercise, you used information from Pod-level fields as the values +for environment variables. +In this next exercise, you are going to pass fields that are part of the Pod +definition, but taken from the specific +[container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) +rather than from the Pod overall. + +Here is a manifest for another Pod that again has just one container: {{< codenew file="pods/inject/dapi-envars-container.yaml" >}} -In the configuration file, you can see four environment variables. The `env` +In this manifest, you can see four environment variables. The `env` field is an array of -[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core). +environment variable definitions. The first element in the array specifies that the `MY_CPU_REQUEST` environment -variable gets its value from the `requests.cpu` field of a Container named +variable gets its value from the `requests.cpu` field of a container named `test-container`. Similarly, the other environment variables get their values -from Container fields. +from fields that are specific to this container. Create the Pod: @@ -134,13 +130,14 @@ Create the Pod: kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml ``` -Verify that the Container in the Pod is running: +Verify that the container in the Pod is running: ```shell +# If the new Pod isn't yet healthy, rerun this command a few times. kubectl get pods ``` -View the Container's logs: +View the container's logs: ```shell kubectl logs dapi-envars-resourcefieldref @@ -155,18 +152,20 @@ The output shows the values of selected environment variables: 67108864 ``` - - ## {{% heading "whatsnext" %}} -* [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/) +* Read [Defining Environment Variables for a Container](/docs/tasks/inject-data-application/define-environment-variable-container/) +* Read the [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) + API definition for Pod. This includes the definition of Container (part of Pod). +* Read the list of [available fields](/docs/concepts/workloads/pods/downward-api/#available-fields) that you + can expose using the downward API. + +Read about Pods, containers and environment variables in the legacy API reference: + * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) * [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core) * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) * [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core) * [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) - - - From 52738ce04b9ccf0aa9bc5a3ea316a2d8b39a49b9 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 27 May 2022 11:17:30 +0900 Subject: [PATCH 062/827] [ko] Update outdated files in dev-1.24-ko.1 M34-M48 --- .../scheduling-eviction/pod-overhead.md | 107 +++++++++--------- .../pod-priority-preemption.md | 6 +- .../resource-bin-packing.md | 25 ++-- .../concepts/security/controlling-access.md | 17 ++- .../services-networking/dns-pod-service.md | 11 -- .../services-networking/dual-stack.md | 2 +- .../services-networking/endpoint-slices.md | 14 ++- .../ingress-controllers.md | 3 +- .../concepts/services-networking/ingress.md | 14 ++- .../services-networking/network-policies.md | 39 +------ .../concepts/services-networking/service.md | 103 ++++++++++++----- .../topology-aware-hints.md | 6 + .../concepts/storage/ephemeral-volumes.md | 32 +++--- .../concepts/storage/persistent-volumes.md | 91 ++++++++++++--- .../service/networking/networkpolicy.yaml | 35 ++++++ 15 files changed, 317 insertions(+), 188 deletions(-) create mode 100644 content/ko/examples/service/networking/networkpolicy.yaml diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index b0da80ceae..0feb96eb9a 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,4 +1,8 @@ --- + + + + title: 파드 오버헤드 content_type: concept weight: 30 @@ -6,17 +10,12 @@ weight: 30 -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} - -노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. +노드 상에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. -_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 -소비되는 리소스를 계산하는 기능이다. - - - - +쿠버네티스에서, _파드 오버헤드_ 는 리소스 요청 및 상한 외에도 +파드의 인프라에 의해 소비되는 리소스를 계산하는 방법 중 하나이다. @@ -25,33 +24,30 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파 [어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 이 수행될 때 지정된다. -파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 -파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 -파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다. +파드를 노드에 스케줄링할 때, 컨테이너 리소스 요청의 합 뿐만 아니라 파드의 오버헤드도 함께 고려된다. +마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도 +파드의 오버헤드를 포함하여 고려한다. -## 파드 오버헤드 활성화하기 {#set-up} +## 파드 오버헤드 환경 설정하기 {#set-up} -기능 활성화를 위해 클러스터에서 -`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화), `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. ## 사용 예제 -파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다. +파드 오버헤드를 활용하려면, `overhead` 필드를 정의하는 런타임클래스가 필요하다. 예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다. ```yaml ---- -kind: RuntimeClass apiVersion: node.k8s.io/v1 +kind: RuntimeClass metadata: - name: kata-fc + name: kata-fc handler: kata-fc overhead: - podFixed: - memory: "120Mi" - cpu: "250m" + podFixed: + memory: "120Mi" + cpu: "250m" ``` `kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, @@ -68,7 +64,7 @@ spec: runtimeClassName: kata-fc containers: - name: busybox-ctr - image: busybox + image: busybox:1.28 stdin: true tty: true resources: @@ -88,13 +84,15 @@ spec: 파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 `overhead` 를 포함하도록 변경한다. -런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다. +런타임클래스 어드미션 컨트롤러가 변경을 완료하면, +다음의 명령어로 업데이트된 파드 오버헤드 값을 확인할 수 있다. ```bash kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` 명령 실행 결과는 다음과 같다. + ``` map[cpu:250m memory:120Mi] ``` @@ -106,23 +104,26 @@ kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다. -일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. +일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 +파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. 기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다. -만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면, -kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 -cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에 -정의된 `overhead` 의 합에 기반한다. +만약 각 컨테이너에 대하여 리소스 상한 제한이 걸려있으면 +(제한이 걸려있는 보장된(Guaranteed) Qos 또는 향상 가능한(Burstable) QoS), +kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 cgroup 의 상한선을 설정한다. +이 상한선은 컨테이너 리소스 상한과 PodSpec에 정의된 `overhead` 의 합에 기반한다. -CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 -리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다. +CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, +kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다. 다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자. + ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` 컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다. + ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` @@ -133,19 +134,21 @@ map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] kubectl describe node | grep test-pod -B2 ``` -CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다. +결과를 보면 2250 m의 CPU와 320 MiB의 메모리가 리소스로 요청되었다. 여기에는 파드 오버헤드가 포함되어 있다. + ``` - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE - --------- ---- ------------ ---------- --------------- ------------- --- - default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m ``` ## 파드 cgroup 상한 확인하기 -워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, -CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. -파드의 오버헤드 동작을 보여주는 좋은 예이며, -사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. +워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인해 보자. +다음의 예제에서, +[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, +CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. +파드 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. 먼저 특정 노드에서 파드의 식별자를 확인해 보자. @@ -155,39 +158,41 @@ POD_ID="$(sudo crictl pods --name test-pod -q)" ``` 여기에서, 파드의 cgroup 경로를 확인할 수 있다. + ```bash # 파드가 스케줄 된 노드에서 이것을 실행 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` 명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다. + ``` - "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` -아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자. +아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. +메모리의 파드 레벨 cgroup 설정을 확인하자. + ```bash # 파드가 스케줄 된 노드에서 이것을 실행. # 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정. cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` -예상대로 320 MiB 이다. +예상한 것과 같이 320 MiB 이다. + ``` 335544320 ``` ### 관찰성 -`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) -에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, -정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. -이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. -그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. - +몇몇 `kube_pod_overhead` 메트릭은 +[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 에서 사용할 수 있어, +파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. ## {{% heading "whatsnext" %}} - -* [런타임클래스](/ko/docs/concepts/containers/runtime-class/) -* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) +* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다. +* 더 자세한 문맥은 + [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index f10ee8524c..778b9b5614 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -104,7 +104,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의 앞쪽에 배치되지만, @@ -203,9 +203,11 @@ spec: 정보를 제공한다. 파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다. +The scheduler always tries the "nominated Node" before iterating over any other nodes. +스케줄러는 다른 노드에 스케줄링을 시도하기 전에 항상 "지정된 노드"부터 시도한다. 피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다. 스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수 -있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과, +있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용할 수 있다. 그 결과, 파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한, 스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가 도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한 diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index c3dcf84727..8c5f19b8ff 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -21,25 +21,24 @@ kube-scheduler를 미세 조정할 수 있다. ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기 -쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 -용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를 -통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 -대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. -`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 -동작은 `RequestedToCapacityRatioArgs`라는 -구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` -두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과 -`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 -조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할 -리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 -구성된다. +쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 +용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. +이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 +대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. +`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 +`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다. +이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. +`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로 +최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. +`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과 +각 리소스의 가중치를 지정하는 `weight` 로 구성된다. 다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: # ... diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index cf2fc529ce..ad30adf3c6 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -1,7 +1,9 @@ --- + + + title: 쿠버네티스 API 접근 제어하기 content_type: concept -weight: 5 --- @@ -29,13 +31,16 @@ API 서버의 인증서에 대한 루트 인증서를 포함하며, 이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다. 클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다. +클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다. + ## 인증 TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다. 이는 다이어그램에 **1**단계로 표시되어 있다. 클러스터 생성 스크립트 또는 클러스터 관리자는 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다. -인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다. +인증기에 대해서는 +[인증](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다. 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다. @@ -46,8 +51,6 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다. 여러 개의 인증 모듈을 지정할 수 있으며, 이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다. -GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다. - 요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다. 이 외에는 사용자가 특정 `username`으로 인증되며, 이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다. @@ -126,6 +129,12 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre 요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후 오브젝트 저장소에 기록(**4**단계)된다. +## 감사(Auditing) + +쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다. +클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다. + +더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다. ## API 서버 포트와 IP diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 75c1d14ccf..9b4521e2b7 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -323,17 +323,6 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화 쿠버네티스는 최대 32개의 탐색 도메인과 최대 2048자의 탐색 도메인 목록을 허용한다. -### 기능 가용성 - -파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다. - -| 쿠버네티스 버전 | 기능 지원 | -| :---------: |:-----------:| -| 1.14 | 안정 | -| 1.10 | 베타 (기본값으로 켜져 있음)| -| 1.9 | 알파 | - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index c17dca7ff9..1e8c9c2a03 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -43,7 +43,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 문서 참조 * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) - * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 + * 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) ## IPv4/IPv6 이중 스택 구성 diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 4ea1281faa..7a3c2f0e0e 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -1,4 +1,6 @@ --- + + title: 엔드포인트슬라이스 content_type: concept weight: 45 @@ -144,12 +146,12 @@ endpoints: v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별 `topology` 가 효과적으로 제거되었다. -`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 -설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신, -v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한 -필드는 API 버전 간에 자동으로 번역된다. 예를 들어, -v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` -키 값은 v1 API의 `zone` 필드로 접근할 수 있다. +`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 설정하는 것은 +더 이상 사용되지 않으며 v1 API에서 지원되지 않는다. +대신, v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. +이러한 필드는 API 버전 간에 자동으로 번역된다. +예를 들어, v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` 키 값은 +v1 API의 `zone` 필드로 접근할 수 있다. {{< /note >}} ### 관리 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 72c68d0563..67073efa4c 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -23,7 +23,7 @@ weight: 40 {{% thirdparty-content %}} -* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다. +* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com/azure/application-gateway/overview)를 구성하는 인그레스 컨트롤러다. * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. @@ -48,6 +48,7 @@ weight: 40 구동하는 인그레스 컨트롤러다. * [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/) 웹서버(프록시로 사용)와 함께 작동한다. +* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다. * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다. * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는 [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index dff0437b00..ba281bf659 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -74,7 +74,7 @@ graph LR; {{< codenew file="service/networking/minimal-ingress.yaml" >}} -다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. +인그레스에는 `apiVersion`, `kind`, `metadata` 및 `spec` 필드가 명시되어야 한다. 인그레스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. @@ -118,8 +118,14 @@ graph LR; ### DefaultBackend {#default-backend} -규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로 -[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다. +규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송하며, +`.spec.defaultBackend`는 이와 같은 경우에 요청을 처리할 백엔드를 지정한다. +`defaultBackend` 는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, +인그레스 리소스에 지정되어 있지 않다. +`.spec.rules` 가 명시되어 있지 않으면, +`.spec.defaultBackend` 는 반드시 명시되어 있어야 한다. +`defaultBackend` 가 설정되어 있지 않으면, 어느 규칙에도 해당되지 않는 요청의 처리는 인그레스 컨트롤러의 구현을 따른다(이러한 +경우를 어떻게 처리하는지 알아보려면 해당 인그레스 컨트롤러 문서를 참고한다). 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은 기본 백엔드로 라우팅 된다. @@ -309,7 +315,7 @@ spec: controller: example.com/ingress-controller parameters: # 이 인그레스클래스에 대한 파라미터는 - # "external-configuration" 환경 설정 네임스페이스에 있는 + # "external-configuration" 네임스페이스에 있는 # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다. scope: Namespace apiGroup: k8s.example.com diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index a7d47701ac..f72d1f0cff 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -45,42 +45,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo 네트워크폴리시 의 예시는 다음과 같다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: test-network-policy - namespace: default -spec: - podSelector: - matchLabels: - role: db - policyTypes: - - Ingress - - Egress - ingress: - - from: - - ipBlock: - cidr: 172.17.0.0/16 - except: - - 172.17.1.0/24 - - namespaceSelector: - matchLabels: - project: myproject - - podSelector: - matchLabels: - role: frontend - ports: - - protocol: TCP - port: 6379 - egress: - - to: - - ipBlock: - cidr: 10.0.0.0/24 - ports: - - protocol: TCP - port: 5978 -``` +{{< codenew file="service/networking/networkpolicy.yaml" >}} {{< note >}} 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. @@ -281,7 +246,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 ## 이름으로 네임스페이스 지정 -{{< feature-state state="beta" for_k8s_version="1.21" >}} +{{< feature-state for_k8s_version="1.22" state="stable" >}} 쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 871323ea2a..858c5ab09a 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -24,7 +24,7 @@ weight: 10 ## 동기 -쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와 +쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 목표 상태(desired state)와 일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다. 만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면, 동적으로 파드를 생성하고 제거할 수 있다. @@ -108,13 +108,46 @@ spec: 필드와 같은 값으로 설정된다. {{< /note >}} -파드의 포트 정의에는 이름이 있고, 서비스의 `targetPort` 속성에서 이 이름을 -참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고, -단일 구성 이름을 사용하는 서비스 내에 -혼합된 파드가 존재해도 가능하다. -이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다. -예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음 -버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다. +파드의 포트 정의에 이름이 있으므로, +서비스의 `targetPort` 속성에서 이 이름을 참조할 수 있다. +예를 들어, 다음과 같은 방법으로 서비스의 `targetPort`를 파드 포트에 바인딩할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + app.kubernetes.io/name: proxy +spec: + containers: + - name: nginx + image: nginx:11.14.2 + ports: + - containerPort: 80 + name: http-web-svc + +--- +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app.kubernetes.io/name: proxy + ports: + - name: name-of-service-port + protocol: TCP + port: 80 + targetPort: http-web-svc +``` + + +이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고, +단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다. +이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다. +예를 들어, 클라이언트를 망가뜨리지 않고, +백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다. 서비스의 기본 프로토콜은 TCP이다. 다른 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다. @@ -125,9 +158,9 @@ spec: ### 셀렉터가 없는 서비스 -서비스는 일반적으로 쿠버네티스 파드에 대한 접근을 추상화하지만, -다른 종류의 백엔드를 추상화할 수도 있다. -예를 들면 +서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만, +셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며, +여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다. * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만, 테스트 환경에서는 자체 데이터베이스를 사용한다. @@ -668,44 +701,38 @@ status: #### 프로토콜 유형이 혼합된 로드밸런서 -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} 기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든 포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가 지원하는 프로토콜이어야 한다. -kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다. +`MixedProtocolLBService` 기능 게이트(v1.24에서 kube-apiserver에 대해 기본적으로 활성화되어 있음)는 +둘 이상의 포트가 정의되어 있는 경우에 로드밸런서 타입의 서비스에 대해 서로 다른 프로토콜을 사용할 수 있도록 해 준다. {{< note >}} 로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다. +클라우드 제공자가 혼합 프로토콜을 지원하지 않는다면 이는 단일 프로토콜만을 제공한다는 것을 의미한다. {{< /note >}} #### 로드밸런서 NodePort 할당 비활성화 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며, 이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다. 노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다. 기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다. -노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 -해당 노드 포트는 자동으로 할당 해제되지 **않는다**. +노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 **않는다**. 이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다. -이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. -쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로, -`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다. -다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다. #### 로드 밸런서 구현 클래스 지정 {#load-balancer-class} -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. -이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. -쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다. 기본적으로, `spec.loadBalancerClass` 는 `nil` 이고, 클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면 `LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다. @@ -1211,7 +1238,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일 충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는 많은 일이 있다. -### 충돌 방지 +### 충돌 방지 {#avoiding-collisions} 쿠버네티스의 주요 철학 중 하나는 잘못한 것이 없는 경우 실패할 수 있는 상황에 노출되어서는 @@ -1219,9 +1246,10 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일 충돌할 경우에 대비해 자신의 포트 번호를 선택하지 않아도 된다. 그것은 격리 실패이다. -서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의 -서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를 -할당하여 이를 수행한다. +서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, +두 개의 서비스가 충돌하지 않도록 해야 한다. +쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서 +각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다. 각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는 각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서 @@ -1235,6 +1263,25 @@ IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다. 할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된 IP 주소를 정리한다. +#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range} + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} +그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데, +그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address). +이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면 +충돌이 발생할 수 있다. + +`ServiceIPStaticSubrange` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, +할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 +`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, +여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. +동적 IP 할당은 상위 대역에서 우선적으로 선택하며, +이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다. +이렇게 함으로써 사용자가 서비스의 고정 IP를 +`service-cluster-ip-range`의 하위 대역에서 할당하면서도 +충돌 위험을 줄일 수 있다. + ### 서비스 IP 주소 {#ips-and-vips} 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리, diff --git a/content/ko/docs/concepts/services-networking/topology-aware-hints.md b/content/ko/docs/concepts/services-networking/topology-aware-hints.md index 7f086a5eee..bf0f1fb8c2 100644 --- a/content/ko/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ko/docs/concepts/services-networking/topology-aware-hints.md @@ -19,6 +19,12 @@ _토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드 예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해, 인접성을 고려하여 트래픽을 라우트할 수 있다. +{{< note >}} +"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**. +이 기능을 사용해 보려면, +`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +{{< /note >}} + ## 동기(motivation) diff --git a/content/ko/docs/concepts/storage/ephemeral-volumes.md b/content/ko/docs/concepts/storage/ephemeral-volumes.md index ea3a05d74b..8a9f11b674 100644 --- a/content/ko/docs/concepts/storage/ephemeral-volumes.md +++ b/content/ko/docs/concepts/storage/ephemeral-volumes.md @@ -107,7 +107,7 @@ metadata: spec: containers: - name: my-frontend - image: busybox + image: busybox:1.28 volumeMounts: - mountPath: "/data" name: my-csi-inline-vol @@ -125,8 +125,19 @@ spec: 더 자세한 사항은 각 CSI 드라이버 문서를 참고한다. -클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며, -[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다. +### CSI 드라이버 제한 사항 + +CSI 임시 볼륨은 사용자로 하여금 `volumeAttributes`를 +파드 스펙의 일부로서 CSI 드라이버에 직접 제공할 수 있도록 한다. +보통은 관리자만 사용할 수 있는 `volumeAttributes`를 허용하는 CSI 드라이버는 +내장(inline) 임시 볼륨 내에서 사용하는 것이 적합하지 않다. +예를 들어, 일반적으로 스토리지클래스 내에 정의되어 있는 파라미터들은 +내장 임시 볼륨 사용을 통해 사용자에게 노출되어서는 안 된다. + +클러스터 관리자가 이처럼 파드 스펙 내장 임시 볼륨 사용이 가능한 CSI 드라이버를 제한하려면 +다음을 수행할 수 있다. +- CSIDriver 스펙의 `volumeLifecycleModes`에서 `Ephemeral`을 제거하여, 해당 드라이버가 내장 임시 볼륨으로 사용되는 것을 막는다. +- [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 드라이버를 활용하는 방법을 제한한다. ### 일반 임시 볼륨 {#generic-ephemeral-volumes} @@ -158,7 +169,7 @@ metadata: spec: containers: - name: my-frontend - image: busybox + image: busybox:1.28 volumeMounts: - mountPath: "/scratch" name: scratch-volume @@ -239,16 +250,9 @@ PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할 GenericEphemeralVolume 기능을 활성화하면 사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며, -심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. -클러스터 관리자는 이를 명심해야 한다. -이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다. -- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우, - [파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를 - 사용한다(쿠버네티스 - 1.21에서 사용 중단됨). -- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는 - [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 - 사용한다. +심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. 클러스터 관리자는 이를 명심해야 한다. +이것이 보안 모델에 부합하지 않는다면, [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 +일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부해야 한다. 일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로, 사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도, diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 8796d2fd50..857d25e8ae 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -175,6 +175,74 @@ spec: 그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다. +### 퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer) {#persistentvolume-deletion-protection-finalizer} +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +퍼시스턴트볼륨에 파이널라이저를 추가하여, `Delete` 반환 정책을 갖는 퍼시스턴트볼륨이 +기반 스토리지(backing storage)가 삭제된 이후에만 삭제되도록 할 수 있다. + +새롭게 도입된 `kubernetes.io/pv-controller` 및 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 +동적으로 프로비전된 볼륨에만 추가된다. + +`kubernetes.io/pv-controller` 파이널라이저는 인-트리 플러그인 볼륨에 추가된다. 다음은 이에 대한 예시이다. + +```shell +kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Labels: +Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: yes + pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume +Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller] +StorageClass: vcp-sc +Status: Bound +Claim: default/vcp-pvc-1 +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 1Gi +Node Affinity: +Message: +Source: + Type: vSphereVolume (a Persistent Disk resource in vSphere) + VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk + FSType: ext4 + StoragePolicyName: vSAN Default Storage Policy +Events: +``` + +`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 CSI 볼륨에 추가된다. +다음은 이에 대한 예시이다. +```shell +Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d +Labels: +Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com +Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer] +StorageClass: fast +Status: Bound +Claim: demo-app/nginx-logs +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 200Mi +Node Affinity: +Message: +Source: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: csi.vsphere.vmware.com + FSType: ext4 + VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd + ReadOnly: false + VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com + type=vSphere CNS Block Volume +Events: +``` + +특정 인-트리 볼륨 플러그인에 대해 `CSIMigration` 기능을 활성화하면 `kubernetes.io/pv-controller` 파이널라이저는 제거되고, +`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저가 추가된다. +이와 비슷하게, `CSIMigration` 기능을 비활성화하면 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 제거되고, +`kubernetes.io/pv-controller` 파이널라이저가 추가된다. + ### 퍼시스턴트볼륨 예약 컨트롤 플레인은 클러스터에서 [퍼시스턴트볼륨클레임을 일치하는 퍼시스턴트볼륨에 바인딩](#바인딩)할 @@ -284,18 +352,13 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 -{{< feature-state for_k8s_version="v1.15" state="beta" >}} - -{{< note >}} -사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. -{{< /note >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다. 파일시스템이 확장되자마자 사용 중인 PVC가 파드에서 자동으로 사용 가능하다. 이 기능은 파드나 디플로이먼트에서 사용하지 않는 PVC에는 영향을 미치지 않는다. 확장을 완료하기 전에 PVC를 사용하는 파드를 만들어야 한다. - 다른 볼륨 유형과 비슷하게 FlexVolume 볼륨도 파드에서 사용 중인 경우 확장할 수 있다. {{< note >}} @@ -329,7 +392,7 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다. {{< /note >}} -클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` +클러스터에 `RecoverVolumeExpansionFailure` 기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. 더 작은 크기를 지정하여 확장 시도를 요청하려면, @@ -849,17 +912,12 @@ spec: ## 볼륨 파퓰레이터(Volume populator)와 데이터 소스 -{{< feature-state for_k8s_version="v1.22" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} -{{< note >}} 쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다. -이 알파 기능은 쿠버네티스 1.18에서 도입되었으며 -1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다. -현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번 -확인한다. {{% version-check %}} -커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해 -`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. -{{< /note >}} +커스텀 볼륨 파퓰레이터를 사용하려면, +kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다. 다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는 @@ -877,6 +935,7 @@ spec: `dataSourceRef` 필드와 `dataSource` 필드 사이에는 사용자가 알고 있어야 할 두 가지 차이점이 있다. + * `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만, `dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다. 유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다. diff --git a/content/ko/examples/service/networking/networkpolicy.yaml b/content/ko/examples/service/networking/networkpolicy.yaml new file mode 100644 index 0000000000..e91eed2f67 --- /dev/null +++ b/content/ko/examples/service/networking/networkpolicy.yaml @@ -0,0 +1,35 @@ +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + - Egress + ingress: + - from: + - ipBlock: + cidr: 172.17.0.0/16 + except: + - 172.17.1.0/24 + - namespaceSelector: + matchLabels: + project: myproject + - podSelector: + matchLabels: + role: frontend + ports: + - protocol: TCP + port: 6379 + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 5978 + From 360335002d639ecd17ed0151b527f4b6fb432c3d Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 27 May 2022 11:23:37 +0900 Subject: [PATCH 063/827] [ko] Update outdated files in dev-1.24-ko.1 M49-M72 --- .../docs/concepts/storage/storage-capacity.md | 33 ++--- .../docs/concepts/storage/storage-classes.md | 6 +- .../storage/volume-health-monitoring.md | 7 +- .../docs/concepts/storage/volume-snapshots.md | 47 +++++++ content/ko/docs/concepts/storage/volumes.md | 115 +++++++----------- .../workloads/controllers/cron-jobs.md | 17 ++- .../workloads/controllers/daemonset.md | 16 +-- .../workloads/controllers/deployment.md | 26 ++-- .../concepts/workloads/controllers/job.md | 27 ++-- .../workloads/controllers/replicaset.md | 2 - .../controllers/replicationcontroller.md | 6 +- .../workloads/controllers/statefulset.md | 31 ++++- .../ko/docs/concepts/workloads/pods/_index.md | 29 +++-- .../concepts/workloads/pods/pod-lifecycle.md | 4 +- .../pods/pod-topology-spread-constraints.md | 70 ++++++----- content/ko/docs/contribute/_index.md | 8 +- content/ko/docs/contribute/advanced.md | 1 + .../contribute/participate/pr-wranglers.md | 17 ++- .../docs/contribute/review/reviewing-prs.md | 4 +- content/ko/docs/home/_index.md | 2 +- content/ko/docs/reference/_index.md | 7 +- 21 files changed, 283 insertions(+), 192 deletions(-) diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index 86c95ae13a..69ce7e9e65 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -16,37 +16,41 @@ weight: 70 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며, 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다. -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고 스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에 -파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다. +[파드를 스케줄링](/ko/docs/concepts/scheduling-eviction/)하기 위해 이 정보를 어떻게 사용하는지 설명한다. 스토리지 용량을 추적하지 않으면, 스케줄러는 볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며, 스케줄링을 여러 번 다시 시도해야 한다. -스토리지 용량 추적은 {{< glossary_tooltip -text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며, -CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다. +## {{% heading "prerequisites" %}} + +쿠버네티스 v{{< skew currentVersion >}} 버전은 스토리지 용량 추적을 위한 클러스터-수준 API를 지원한다. +이를 사용하려면, 스토리지 용량 추적을 지원하는 CSI 드라이버를 사용하고 있어야 한다. +사용 중인 CSI 드라이버가 이를 지원하는지, 지원한다면 어떻게 사용하는지를 알아보려면 +해당 CSI 드라이버의 문서를 참고한다. +쿠버네티스 v{{< skew currentVersion >}} 버전을 사용하고 있지 않다면, +해당 버전 쿠버네티스 문서를 참고한다. ## API 이 기능에는 다음 두 가지 API 확장이 있다. -- CSIStorageCapacity 오브젝트: +- [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/) 오브젝트: CSI 드라이버가 설치된 네임스페이스에 CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는 하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며, 어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다. -- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): +- [`CSIDriverSpec.StorageCapacity` 필드](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec): `true`로 설정하면, 쿠버네티스 스케줄러가 CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다. ## 스케줄링 다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다. -- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고, - 파드가 아직 생성되지 않은 볼륨을 사용하고, - 해당 볼륨은 CSI 드라이버를 참조하고 `WaitForFirstConsumer` @@ -97,20 +101,9 @@ CSI 스토리지 드라이버에 볼륨 생성을 요청한다 토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어 다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다. 이러한 상황을 복구하려면 -용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며, -자동으로 처리하려면 -[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다. - -## 스토리지 용량 추적 활성화 - -스토리지 용량 추적은 베타 기능이며, -쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다. -클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다. -자세한 내용은 드라이버 문서를 참조한다. +용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하다. ## {{% heading "whatsnext" %}} - 설계에 대한 자세한 내용은 [파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다. -- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다. -- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다. diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 4fff50dced..970b7f3ddd 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -87,7 +87,7 @@ volumeBindingMode: Immediate 여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이 이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와 함께 제공된다). 또한, 쿠버네티스에서 정의한 -[사양](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)을 +[사양](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)을 따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다. 외부 프로비저너의 작성자는 코드의 수명, 프로비저너의 배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인 @@ -241,8 +241,8 @@ allowedTopologies: - matchLabelExpressions: - key: failure-domain.beta.kubernetes.io/zone values: - - us-central1-a - - us-central1-b + - us-central-1a + - us-central-1b ``` ## 파라미터 diff --git a/content/ko/docs/concepts/storage/volume-health-monitoring.md b/content/ko/docs/concepts/storage/volume-health-monitoring.md index ce149165da..99cc8ca353 100644 --- a/content/ko/docs/concepts/storage/volume-health-monitoring.md +++ b/content/ko/docs/concepts/storage/volume-health-monitoring.md @@ -1,4 +1,9 @@ --- + + + + + title: 볼륨 헬스 모니터링 content_type: concept --- @@ -19,7 +24,7 @@ CSI 드라이버가 컨트롤러 측의 볼륨 헬스 모니터링 기능을 지 외부 헬스 모니터 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 노드 장애 이벤트도 감시한다. `enable-node-watcher` 플래그를 true로 설정하여 노드 장애 모니터링을 활성화할 수 있다. 외부 헬스 모니터가 노드 장애 이벤트를 감지하면, 컨트롤러는 이 PVC를 사용하는 파드가 장애 상태인 노드에 있음을 나타내는 이벤트가 PVC에 보고된다고 알린다. -CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다. +CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다. 그리고, 볼륨 헬스 정보는 kubelet VolumeStats 메트릭 형태로 노출된다. 새로운 kubelet_volume_stats_health_status_abnormal 메트릭이 추가되었다. 이 메트릭은 `namespace` 및 `persistentvolumeclaim` 2개의 레이블을 포함한다. 카운터는 1 또는 0이다. 카운터가 1이면 볼륨이 정상적이지 않음을, 0이면 정상적임을 의미한다. 더 많은 정보는 [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor#kubelet-metrics-changes)를 참고한다. {{< note >}} 노드 측에서 이 기능을 사용하려면 `CSIVolumeHealth` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index d54ed5c45c..0d02310ae8 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -120,6 +120,7 @@ spec: driver: hostpath.csi.k8s.io source: volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002 + sourceVolumeMode: Filesystem volumeSnapshotClassName: csi-hostpath-snapclass volumeSnapshotRef: name: new-snapshot-test @@ -141,6 +142,7 @@ spec: driver: hostpath.csi.k8s.io source: snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 + sourceVolumeMode: Filesystem volumeSnapshotRef: name: new-snapshot-test namespace: default @@ -148,6 +150,51 @@ spec: `snapshotHandle` 은 스토리지 백엔드에서 생성된 볼륨 스냅샷의 고유 식별자이다. 이 필드는 사전 프로비저닝된 스냅샷에 필요하다. `VolumeSnapshotContent` 가 나타내는 스토리지 시스템의 CSI 스냅샷 id를 지정한다. +`sourceVolumeMode` 은 스냅샷이 생성된 볼륨의 모드를 나타낸다. +`sourceVolumeMode` 필드의 값은 `Filesystem` 또는 `Block` 일 수 있다. +소스 볼륨 모드가 명시되어 있지 않으면, +쿠버네티스는 해당 스냅샷의 소스 볼륨 모드를 알려지지 않은 상태(unknown)로 간주하여 스냅샷을 처리한다. + +## 스냅샷의 볼륨 모드 변환하기 {#convert-volume-mode} + +클러스터에 설치된 `VolumeSnapshots` API가 `sourceVolumeMode` 필드를 지원한다면, +인증되지 않은 사용자가 볼륨의 모드를 변경하는 것을 금지하는 기능이 +API에 있는 것이다. + +클러스터가 이 기능을 지원하는지 확인하려면, 다음 명령어를 실행한다. + +```yaml +$ kubectl get crd volumesnapshotcontent -o yaml +``` + +사용자가 기존 `VolumeSnapshot`으로부터 `PersistentVolumeClaim`을 생성할 때 +기존 소스와 다른 볼륨 모드를 지정할 수 있도록 하려면, +`VolumeSnapshot`와 연관된 `VolumeSnapshotContent`에 +`snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` 어노테이션을 추가해야 한다. + +이전에 프로비전된 스냅샷의 경우에는, +클러스터 관리자가 `Spec.SourceVolumeMode`를 추가해야 한다. + +이 기능이 활성화된 예시 `VolumeSnapshotContent` 리소스는 다음과 같을 것이다. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotContent +metadata: + name: new-snapshot-content-test + annotations: + - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true" +spec: + deletionPolicy: Delete + driver: hostpath.csi.k8s.io + source: + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 + sourceVolumeMode: Filesystem + volumeSnapshotRef: + name: new-snapshot-test + namespace: default +``` + ## 스냅샷을 위한 프로비저닝 볼륨 `PersistentVolumeClaim` 오브젝트의 *dataSource* 필드를 사용하여 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 4ce85817f5..c7f6a2df5a 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -143,14 +143,20 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 -`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI -드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) -를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk` -기능을 활성화해야 한다. +`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, +기존 인-트리 플러그인의 모든 플러그인 작업을 +`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) 를 설치하고 +`CSIMigration` 기능을 활성화해야 한다. + +#### azureDisk CSI 마이그레이션 완료 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +컨트롤러 매니저 및 kubelet이 `azureDisk` 스토리지 플러그인을 로드하지 않도록 하려면, +`InTreePluginAzureDiskUnregister` 플래그를 `true`로 설정한다. ### azureFile {#azurefile} @@ -170,7 +176,15 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} + +컨트롤러 매니저 및 kubelet이 `azureFile` 스토리지 플러그인을 로드하지 않도록 하려면, +`InTreePluginAzureFileUnregister` 플래그를 `true`로 설정한다. ### cephfs @@ -219,17 +233,17 @@ spec: #### 오픈스택 CSI 마이그레이션 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -Cinder의`CSIMigration` 기능은 Kubernetes 1.21에서 기본적으로 활성화됩니다. +Cinder의`CSIMigration` 기능은 Kubernetes 1.21부터 기본적으로 활성화되어 있다. 기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. [오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)가 클러스터에 설치되어 있어야 한다. -`CSIMigrationOpenStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -`false` 로 설정하여 클러스터에 대한 Cinder CSI 마이그레이션을 비활성화할 수 있다. -`CSIMigrationOpenStack` 기능을 비활성화하면, 트리 내 Cinder 볼륨 플러그인이 -Cinder 볼륨 스토리지 관리의 모든 측면을 담당한다. + +컨트롤러 매니저 및 kubelet이 인-트리 Cinder 플러그인을 로드하지 않도록 하려면, +`InTreePluginOpenStackUnregister` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. ### 컨피그맵(configMap) {#configmap} @@ -251,7 +265,7 @@ metadata: spec: containers: - name: test - image: busybox + image: busybox:1.28 volumeMounts: - name: config-vol mountPath: /etc/config @@ -879,9 +893,7 @@ RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 * 또한, 트리 내(in-tree) 스토리지클래스의 `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 `adminSecretName` 값이 `adminId` 파라미터 값의 - base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. - -{{< /note >}} + base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. {{< /note >}} ### secret @@ -957,66 +969,15 @@ spec: StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 더 자세한 정보는 [StorageOS 예제](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 참고한다. -### vsphereVolume {#vspherevolume} +### vsphereVolume (사용 중단됨) {#vspherevolume} {{< note >}} -쿠버네티스 vSphere 클라우드 공급자를 구성해야 한다. 클라우드공급자 -구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다. +이 드라이버 대신 외부(out-of-tree) vSphere CSI 드라이버를 사용하는 것을 권장한다. {{< /note >}} `vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다. 볼륨을 마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다. -{{< note >}} -파드와 함께 사용하기 위해선 먼저 다음 방법 중 하나를 사용하여 vSphere VMDK 볼륨을 생성해야 한다. -{{< /note >}} - -#### VMDK 볼륨 생성하기 {#creating-vmdk-volume} - -다음 중 하나를 선택해서 VMDK를 생성한다. - -{{< tabs name="tabs_volumes" >}} -{{% tab name="vmkfstools를 사용해서 생성" %}} -먼저 ESX에 ssh로 들어간 다음, 다음 명령을 사용해서 VMDK를 생성한다. - -```shell -vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk -``` - -{{% /tab %}} -{{% tab name="vmware-vdiskmanager를 사용해서 생성" %}} -다음 명령을 사용해서 VMDK를 생성한다. - -```shell -vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk -``` - -{{% /tab %}} - -{{< /tabs >}} - -#### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-vmdk -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: test-container - volumeMounts: - - mountPath: /test-vmdk - name: test-volume - volumes: - - name: test-volume - # 이 VMDK 볼륨은 이미 있어야 한다. - vsphereVolume: - volumePath: "[DatastoreName] volumes/myDisk" - fsType: ext4 -``` - 더 자세한 내용은 [vSphere 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) 예제를 참고한다. #### vSphere CSI 마이그레이션 {#vsphere-csi-migration} @@ -1028,8 +989,15 @@ spec: [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. +마이그레이션에 대한 추가 조언은 VMware의 문서 페이지 +[인-트리 vSphere 볼륨을 vSphere 컨테이너 스토리지 플러그인으로 마이그레이션하기](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html)를 참고한다. -또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다. +쿠버네티스 v{{< skew currentVersion >}} 버전에서 외부(out-of-tree) CSI 드라이버로 마이그레이션하려면 +vSphere 7.0u2 이상을 사용하고 있어야 한다. +v{{< skew currentVersion >}} 외의 쿠버네티스 버전을 사용 중인 경우, +해당 쿠버네티스 버전의 문서를 참고한다. +쿠버네티스 v{{< skew currentVersion >}} 버전과 vSphere 이전 버전을 사용 중이라면, +vSphere 버전을 7.0u2 이상으로 업그레이드하는 것을 추천한다. {{< note >}} 빌트인 `vsphereVolume` 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. @@ -1130,7 +1098,7 @@ spec: fieldRef: apiVersion: v1 fieldPath: metadata.name - image: busybox + image: busybox:1.28 command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] volumeMounts: - name: workdir1 @@ -1199,7 +1167,6 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 * [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서 * [일반 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)과 함께 - (알파 기능) * 드라이버가 지원하는 경우 [CSI 임시 볼륨](/ko/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)과 함께 (베타 기능) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 34ac547b73..7ab8eca81e 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -69,7 +69,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 # │ │ │ ┌───────────── 월 (1 - 12) # │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지; # │ │ │ │ │ 특정 시스템에서는 7도 일요일) -# │ │ │ │ │ +# │ │ │ │ │ 또는 sun, mon, tue, wed, thu, fri, sat # │ │ │ │ │ # * * * * * ``` @@ -91,6 +91,21 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다. +## 타임 존 +크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다. + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} + +`CronJobTimeZone` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, +크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나, +타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우, +클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다). + +이 기능을 활성화하면, `spec.timeZone`을 유효한 [타임 존](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 이름으로 지정할 수 있다. +예를 들어, `spec.timeZone: "Etc/UTC"`와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다. + +Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다. + ## 크론잡의 한계 {#cron-job-limitations} 크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 33b8812d1a..ffd07afd9a 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -76,11 +76,11 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.selector` 필드는 파드 셀렉터이다. 이것은 [잡](/ko/docs/concepts/workloads/controllers/job/)의 `.spec.selector` 와 같은 동작을 한다. -쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. -파드 셀렉터는 비워두면 더 이상 기본 값이 설정이 되지 않는다. -셀렉터의 기본 값은 `kubectl apply` 과 호환되지 않는다. -또한, 한 번 데몬셋이 만들어지면 `.spec.selector` 의 변형은 가능하지 않다. -파드 셀렉터를 변형하면 의도하지 않게 파드는 고아가 되거나 사용자에게 혼란을 주는 것으로 밝혀졌다. +`.spec.template`의 레이블과 매치되는 +파드 셀렉터를 명시해야 한다. +또한, 한 번 데몬셋이 만들어지면 +`.spec.selector` 는 바꿀 수 없다. +파드 셀렉터를 변형하면 의도치 않게 파드가 고아가 될 수 있으며, 이는 사용자에게 혼란을 주는 것으로 밝혀졌다. `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다. @@ -91,8 +91,8 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다. -만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. -일치하지 않는 구성은 API에 의해 거부된다. +`.spec.selector` 는 `.spec.template.metadata.labels` 와 일치해야 한다. +이 둘이 서로 일치하지 않는 구성은 API에 의해 거부된다. ### 오직 일부 노드에서만 파드 실행 @@ -107,7 +107,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 기본 스케줄러로 스케줄 -{{< feature-state state="stable" for-kubernetes-version="1.17" >}} +{{< feature-state for_k8s_version="1.17" state="stable" >}} 데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 440307f381..395ad1b73a 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -255,10 +255,11 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. 기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). - 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 - 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, - 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. - 이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. + 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음, + 이전 파드를 삭제하고, 또 다른 새로운 파드를 만든 것을 볼 수 있다. + 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. + 이것은 최소 3개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. + 디플로이먼트의 레플리카 크기가 4인 경우, 파드 숫자는 3개에서 5개 사이이다. * 디플로이먼트의 세부 정보 가져오기 ```shell @@ -303,13 +304,20 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 ``` - 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 - 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. - 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 - 이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다. - 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. + 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성하고 + 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. + 디플로이먼트를 업데이트하자, 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 모두 실행될 때까지 대기하였다. + 그 뒤 이전 레플리카셋을 2개로 스케일 다운하고 새 레플리카셋을 2개로 스케일 업하여 모든 시점에 대해 최소 3개 / 최대 3개의 파드가 존재하도록 하였다. + 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다. +{{< note >}} +쿠버네티스가 `availableReplicas` 수를 계산할 때 종료 중인(terminating) 파드는 포함하지 않으며, +이 수는 `replicas - maxUnavailable` 와 `replicas + maxSurge` 사이에 존재한다. +그 결과, 롤아웃 중에는 파드의 수가 예상보다 많을 수 있으며, +종료 중인 파드의 `terminationGracePeriodSeconds`가 만료될 때까지는 디플로이먼트가 소비하는 총 리소스가 `replicas + maxSurge` 이상일 수 있다. +{{< /note >}} + ### 롤오버(일명 인-플라이트 다중 업데이트) 디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 06ce527869..1c05462b10 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -42,7 +42,9 @@ weight: 50 ```shell kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml ``` + 출력 결과는 다음과 같다. + ``` job.batch/pi created ``` @@ -52,7 +54,9 @@ job.batch/pi created ```shell kubectl describe jobs/pi ``` + 출력 결과는 다음과 같다. + ``` Name: pi Namespace: default @@ -97,7 +101,9 @@ Events: pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') echo $pods ``` + 출력 결과는 다음과 같다. + ``` pi-5rwd7 ``` @@ -110,7 +116,9 @@ pi-5rwd7 ```shell kubectl logs $pods ``` + 출력 결과는 다음과 같다. + ```shell 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` @@ -190,7 +198,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 ### 완료 모드 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다. @@ -308,7 +316,7 @@ spec: ### 완료된 잡을 위한 TTL 메커니즘 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해 @@ -425,13 +433,7 @@ spec: ### 잡 일시 중지 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} - -{{< note >}} -이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, -이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. -[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다. -{{< /note >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해 즉시 파드 생성을 시작하고 잡이 완료될 때까지 @@ -482,7 +484,7 @@ spec: kubectl get jobs/myjob -o yaml ``` -```json +```yaml apiVersion: batch/v1 kind: Job # .metadata and .spec omitted @@ -581,7 +583,9 @@ Events: ```shell kubectl get job old -o yaml ``` + 출력 결과는 다음과 같다. + ```yaml kind: Job metadata: @@ -631,7 +635,8 @@ spec: 이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. 이 기능이 활성화되기 이전에 생성된 잡은 영향을 받지 않는다. -사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. +사용자가 느낄 수 있는 유일한 차이점은 +컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. {{< /note >}} 이 기능이 활성화되지 않으면, 잡 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index e03f2bedb7..5a799680b2 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -223,8 +223,6 @@ pod2 1/1 Running 0 36s 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다. 레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다. -쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다. -API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. 레플리카셋 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index bcf8a9771a..3de8fbfc02 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -185,8 +185,8 @@ delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 를 사용 Kubectl은 레플리케이션 컨트롤러를 0으로 스케일하고 레플리케이션 컨트롤러 자체를 삭제하기 전에 각 파드를 삭제하기를 기다린다. 이 kubectl 명령이 인터럽트되면 다시 시작할 수 있다. -REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, -레플리케이션 컨트롤러를 삭제). +REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 +명시적으로 단계를 수행해야 한다(레플리카를 0으로 스케일하고 파드의 삭제를 기다린 이후, 레플리케이션 컨트롤러를 삭제). ### 레플리케이션 컨트롤러만 삭제 @@ -194,7 +194,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 명시적 kubectl을 사용하여, [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)에 옵션으로 `--cascade=orphan`을 지정하라. -REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라. +REST API나 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries)를 사용하는 경우 레플리케이션 컨트롤러 오브젝트를 삭제하라. 원본이 삭제되면 대체할 새로운 레플리케이션 컨트롤러를 생성하여 교체할 수 있다. 오래된 파드와 새로운 파드의 `.spec.selector` 가 동일하다면, 새로운 레플리케이션 컨트롤러는 오래된 파드를 채택할 것이다. 그러나 기존 파드를 diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index ff9eca9155..f63a7cbc7d 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -115,7 +115,7 @@ spec: ### 파드 셀렉터 -스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 1.8 버전 이상에서는, 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다. +스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정해야 한다. 해당되는 파드 셀렉터를 찾지 못하면 스테이트풀셋 생성 과정에서 검증 오류가 발생한다. ### 볼륨 클레임 템플릿 @@ -226,8 +226,8 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 되기 전까지 종료되지 않는다. ### 파드 관리 정책 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 -통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. +스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 +고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. #### OrderedReady 파드 관리 @@ -266,7 +266,9 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 각 파드의 업데이트는 한 번에 하나씩 한다. 쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다. -`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다. +`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 +설정한 경우, +컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다. ### 파티션 롤링 업데이트 {#partitions} @@ -280,6 +282,27 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. +### 최대 사용 불가능(unavailable) 파드 수 + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} + +`.spec.updateStrategy.rollingUpdate.maxUnavailable` 필드를 명시하여, +업데이트 과정에서 사용 불가능(unavailable) 파드를 최대 몇 개까지 허용할 것인지를 조절할 수 있다. +값은 절대값(예: `5`) 또는 목표 파드 퍼센티지(예: `10%`)로 명시할 수 있다. +절대값은 퍼센티지 값으로 계산한 뒤 올림하여 얻는다. +이 필드는 0일 수 없다. 기본값은 1이다. + +이 필드는 `0` 에서 `replicas - 1` 사이 범위에 있는 모든 파드에 적용된다. +이 범위 내에 사용 불가능한 파드가 있으면, +`maxUnavailable`로 집계된다. + +{{< note >}} +`maxUnavailable` 필드는 현재 알파 단계이며 +`MaxUnavailableStatefulSet` +[기능 게이트](/ko/docs/reference/commmand-line-tools-reference/feature-gates/)가 활성화된 API 서버에서만 +동작한다. +{{< /note >}} + ### 강제 롤백 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 6a13adb91f..ce0c620392 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -180,7 +180,7 @@ spec: spec: containers: - name: hello - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] restartPolicy: OnFailure # 여기까지 파드 템플릿이다 @@ -251,20 +251,19 @@ spec: ### 파드 네트워킹 -각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. 파드의 -모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를 -공유한다. 파드 내부(그때 **만** 해당)에서, 파드에 속한 -컨테이너는 `localhost` 를 사용하여 서로 통신할 수 있다. 파드의 컨테이너가 -*파드 외부의* 엔티티와 통신할 때, -공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. -파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, -`localhost` 를 통해 서로를 찾을 수 있다. 파드의 컨테이너는 SystemV 세마포어 또는 -POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로 -통신할 수도 있다. 다른 파드의 컨테이너는 -고유한 IP 주소를 가지며 -[특별한 구성](/ko/docs/concepts/policy/pod-security-policy/) 없이 IPC로 통신할 수 없다. -다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 -사용하여 통신할 수 있다. +각 파드에는 각 주소 패밀리에 대해 고유한 IP 주소가 할당된다. +파드의 모든 컨테이너는 네트워크 네임스페이스를 공유하며, +여기에는 IP 주소와 네트워크 포트가 포함된다. +파드 내부(이 경우에 **만** 해당)에서, 파드에 속한 컨테이너는 +`localhost` 를 사용하여 서로 통신할 수 있다. +파드의 컨테이너가 *파드 외부의* 엔티티와 통신할 때, +공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 한다. +파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, +`localhost` 를 통해 서로를 찾을 수 있다. +파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 +표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있다. +다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 OS 수준의 IPC로 통신할 수 없다. +다른 파드에서 실행되는 컨테이너와 상호 작용하려는 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다. 파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된 `name` 과 동일한 것으로 간주한다. [네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션에 이에 대한 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index fbaa26548a..b5a83a7720 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -136,8 +136,8 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되 쿼리하면, 이유와 종료 코드 그리고 해당 컨테이너의 실행 기간에 대한 시작과 종료 시간이 표시된다. -컨테이너에 구성된 `preStop` 훅이 있는 경우, 컨테이너가 `Terminated` 상태에 들어가기 전에 -실행된다. +컨테이너에 구성된 `preStop` 훅이 있는 경우, +이 혹은 컨테이너가 `Terminated` 상태에 들어가기 전에 실행된다. ## 컨테이너 재시작 정책 {#restart-policy} diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index d25f001607..ee458256f5 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -4,21 +4,11 @@ content_type: concept weight: 40 --- -{{< feature-state for_k8s_version="v1.19" state="stable" >}} - 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. -{{< note >}} -v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 -[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 -[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서 -`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화해야 한다 -{{< /note >}} @@ -83,16 +73,42 @@ spec: - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. 이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다. + - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는 대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 - (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0) + (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. + 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, + 전역 최솟값은 0) 사이에 허용되는 최대 차이이다. - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는 왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다. + +- **minDomains** 는 적합한(eligible) 도메인의 최소 수를 나타낸다. + 도메인은 토폴로지의 특정 인스턴스 중 하나이다. + 도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다. + + - `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다. + - 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 적으면, + 파드 토폴로지 스프레드는 "글로벌 미니멈"을 0으로 간주한 뒤, `skew` 계산이 수행된다. + "글로벌 미니멈"은 적합한 도메인 내에 매치되는 파드의 최소 수 이며, + 적합한 도메인 수가 `minDomains`보다 적은 경우에는 0이다. + - 매치되는 토폴로지 키의 적합한 도메인 수가 `minDomains`보다 크거나 같으면, + 이 값은 스케줄링에 영향을 미치지 않는다. + - `minDomains`가 nil이면, 이 제약은 `minDomains`가 1인 것처럼 동작한다. + - `minDomains`가 nil이 아니면, `whenUnsatisfiable`의 값은 "`DoNotSchedule`"이어야 한다. + + {{< note >}} + `minDomains` 필드는 1.24에서 추가된 알파 필드이다. + 이를 사용하려면 `MinDomainsInPodToplogySpread` + [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. + {{< /note >}} + - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다. + - **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 처리하는 방법을 나타낸다. - `DoNotSchedule` (기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다. - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다. + - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다. 파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다. @@ -306,11 +322,12 @@ class zoneC cluster; 예시 구성은 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - - pluginConfig: + - schedulerName: default-scheduler + pluginConfig: - name: PodTopologySpread args: defaultConstraints: @@ -321,21 +338,17 @@ profiles: ``` {{< note >}} -기본 스케줄링 제약 조건에 의해 생성된 점수는 -[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에 -의해 생성된 점수와 충돌 할 수 있다. -`PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서 -이 플러그인을 비활성화 하는 것을 권장한다. +[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)은 +기본적으로 비활성화되어 있다. +비슷한 효과를 얻기 위해 `PodTopologySpread`를 사용하는 것을 추천한다. {{< /note >}} -#### 내부 기본 제약 +#### 내장 기본 제약 {#internal-default-constraints} -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -기본적으로 활성화된 `DefaultPodTopologySpread` 기능 게이트를 사용하면, 기존 -`SelectorSpread` 플러그인이 비활성화된다. -kube-scheduler는 `PodTopologySpread` 플러그인 구성에 다음과 같은 -기본 토폴로지 제약 조건을 사용한다. +파드 토폴로지 스프레딩에 대해 클러스터 수준의 기본 제약을 설정하지 않으면, +kube-scheduler는 다음과 같은 기본 토폴로지 제약을 설정한 것처럼 동작한다. ```yaml defaultConstraints: @@ -347,8 +360,8 @@ defaultConstraints: whenUnsatisfiable: ScheduleAnyway ``` -또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인이 -비활성화된다. +또한, 같은 동작을 제공하는 레거시 `SelectorSpread` 플러그인은 +기본적으로 비활성화되어 있다. {{< note >}} `PodTopologySpread` 플러그인은 분배 제약 조건에 지정된 토폴로지 키가 @@ -366,11 +379,12 @@ defaultConstraints: `defaultConstraints` 를 비워두어 기본값을 비활성화할 수 있다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - - pluginConfig: + - schedulerName: default-scheduler + pluginConfig: - name: PodTopologySpread args: defaultConstraints: [] diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 64b7ba594e..62b98b68d3 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -95,9 +95,9 @@ class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey class S,T,U spacewhite class first,second,third white {{}} -***그림 - 신규 기여자를 위한 시작 가이드*** +그림 1. 신규 기여자를 위한 시작 가이드. -위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다! +그림 1은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다! 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다. 역할과 권한에 대한 자세한 내용은 @@ -105,7 +105,7 @@ class first,second,third white ## 첫 번째 기여 -몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다. +몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 그림 2는 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다. @@ -136,7 +136,7 @@ class A,B,D,E,F,G grey class S,T spacewhite class first,second white {{}} -***그림 - 첫 기여를 위한 준비*** +그림 2. 첫 기여를 위한 준비. - [기여 개요](/ko/docs/contribute/new-content/)를 읽고 기여할 수 있는 다양한 방법에 대해 알아봅니다. diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index 9b4f8835e3..e40ebc71c1 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -86,6 +86,7 @@ SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/ - 문서 리포지터리에 대한 처음 몇 번의 PR을 통해 새로운 기여자를 멘토링한다. - 새로운 기여자가 쿠버네티스 멤버가 되기 위해 필요한 보다 복잡한 PR을 작성하도록 지원한다. - 쿠버네티스 멤버 가입을 위해 [기여자를 후원](/ko/docs/contribute/advanced/#새로운-기여자-후원)한다. +- 월간 미팅을 개최하여 새로운 기여자에게 도움을 주고 조언을 해 준다. 현재 새로운 기여자 홍보대사는 각 SIG-Docs 회의와 [쿠버네티스 #sig-docs 채널](https://kubernetes.slack.com)에서 발표된다. diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index 424f9b0227..15bcd2198d 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -48,8 +48,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. CLA에 서명한 후 PR을 열 수 있음을 알린다. **작성자가 CLA에 서명하지 않은 PR은 리뷰하지 않는다!** - [LGTM 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm): - 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 - 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. + 멤버의 LGTM이 필요한 PR을 나열한다. PR에 기술 리뷰가 필요한 경우, 봇이 제안한 리뷰어 중 한 명을 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+): 병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다. - [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) @@ -88,3 +87,17 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. [`fejta-bot`](https://github.com/fejta-bot)이라는 봇은 90일 동안 활동이 없으면 이슈를 오래된 것(stale)으로 표시한다. 30일이 더 지나면 rotten으로 표시하고 종료한다. PR 랭글러는 14-30일 동안 활동이 없으면 이슈를 닫아야 한다. {{< /note >}} + +## PR 랭글러 섀도우 프로그램 + +2021년 말에, SIG Docs는 PR 랭글러 섀도우 프로그램을 도입했다. 이 프로그램은 새로운 기여자가 PR 랭글링 과정을 이해하는 데 도움을 주기 위해 도입되었다. + +### 섀도우 되기 + +- PR 랭글러 섀도우 활동에 관심이 있다면, [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)에서 올해의 PR 랭글링 스케줄을 확인하고 지원한다. + +- 쿠버네티스 org 멤버는 [PR 랭글러 위키 페이지](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수정하여 기존 PR 랭글러를 1주일 간 섀도잉할 수 있다. + +- 쿠버네티스 org 비 멤버는 [#sig-docs 슬랙 채널](https://kubernetes.slack.com/messages/sig-docs)에서 특정 주간에 대해 기존 PR 랭글러에 대한 섀도잉을 요청할 수 있다. Brad Topol (`@bradtopol`) 또는 [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 중 한 명에게 연락하면 된다. + +- PR 랭글러 섀도워로 지원했다면, [쿠버네티스 슬랙](https://slack.k8s.io)에서 PR 랭글러에게 자신을 소개한다. diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index e6bb3dc84c..91f8627e17 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -36,7 +36,7 @@ weight: 10 ## 리뷰 과정 -일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다. +일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다. @@ -67,7 +67,7 @@ class S,T spacewhite class third,fourth white {{}} -***그림 - 리뷰 과정 절차*** +그림 1. 리뷰 과정 절차. 1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 이동한다. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 5233856648..5becc565f9 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -60,7 +60,7 @@ cards: title: K8s 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. button: "쿠버네티스 다운로드" - button_path: "/docs/setup/release/notes" + button_path: "/releases/download" - name: about title: 문서에 대하여 description: 이 웹사이트는 현재 버전과 이전 4개 버전의 쿠버네티스 문서를 포함한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index ca824db37d..0f1f0d7155 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -43,7 +43,7 @@ no_list: true ## CLI -* [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. +* [kubectl](/ko/docs/reference/kubectl/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. @@ -66,6 +66,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 * 컨트롤 플레인과 워커 노드에서 꼭 열어야 하는 [포트와 프로토콜](/ko/docs/reference/ports-and-protocols/) 리스트 + ## API 설정 이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 @@ -73,10 +74,12 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 제공하지 않는다. - +* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) * [kube-apiserver 환경설정 (v1)](/docs/reference/config-api/apiserver-config.v1/) +* [kube-apiserver 암호화 (v1)](/docs/reference/config-api/apiserver-encryption.v1/) * [kubelet 환경설정 (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) 및 [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) +* [kubelet 크리덴셜 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) * [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 및 [kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) From 060b924df8feb7bb23d3f33c14602fbb16986498 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 13 Mar 2022 13:59:18 +0800 Subject: [PATCH 064/827] Tweak the share process namespace page This PR removes the outdated information about very old versions of k8s releases. It also revises the indentation of unordered lists. Some other trivial clarifications of text are applied as well. --- .../share-process-namespace.md | 93 ++++++++++--------- 1 file changed, 49 insertions(+), 44 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md index dfb8e40906..773a0b6544 100644 --- a/content/en/docs/tasks/configure-pod-container/share-process-namespace.md +++ b/content/en/docs/tasks/configure-pod-container/share-process-namespace.md @@ -1,6 +1,5 @@ --- title: Share Process Namespace between Containers in a Pod -min-kubernetes-server-version: v1.10 reviewers: - verb - yujuhong @@ -11,64 +10,69 @@ weight: 160 -{{< feature-state state="stable" for_k8s_version="v1.17" >}} - This page shows how to configure process namespace sharing for a pod. When process namespace sharing is enabled, processes in a container are visible -to all other containers in that pod. +to all other containers in the same pod. You can use this feature to configure cooperating containers, such as a log handler sidecar container, or to troubleshoot container images that don't include debugging utilities like a shell. - - ## {{% heading "prerequisites" %}} - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - +{{< include "task-tutorial-prereqs.md" >}} ## Configure a Pod -Process Namespace Sharing is enabled using the `shareProcessNamespace` field of -`v1.PodSpec`. For example: +Process namespace sharing is enabled using the `shareProcessNamespace` field of +`.spec` for a Pod. For example: {{< codenew file="pods/share-process-namespace.yaml" >}} 1. Create the pod `nginx` on your cluster: - ```shell - kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml + ``` 1. Attach to the `shell` container and run `ps`: - ```shell - kubectl attach -it nginx -c shell - ``` + ```shell + kubectl attach -it nginx -c shell + ``` - If you don't see a command prompt, try pressing enter. + If you don't see a command prompt, try pressing enter. In the container shell: - ``` - / # ps ax - PID USER TIME COMMAND - 1 root 0:00 /pause - 8 root 0:00 nginx: master process nginx -g daemon off; - 14 101 0:00 nginx: worker process - 15 root 0:00 sh - 21 root 0:00 ps ax - ``` + ```shell + # run this inside the "shell" container + ps ax + ``` + + The output is similar to this: + + ```none + PID USER TIME COMMAND + 1 root 0:00 /pause + 8 root 0:00 nginx: master process nginx -g daemon off; + 14 101 0:00 nginx: worker process + 15 root 0:00 sh + 21 root 0:00 ps ax + ``` You can signal processes in other containers. For example, send `SIGHUP` to -nginx to restart the worker process. This requires the `SYS_PTRACE` capability. +`nginx` to restart the worker process. This requires the `SYS_PTRACE` capability. +```shell +# run this inside the "shell" container +kill -HUP 8 # change "8" to match the PID of the nginx leader process, if necessary +ps ax ``` -/ # kill -HUP 8 -/ # ps ax + +The output is similar to this: + +```none PID USER TIME COMMAND 1 root 0:00 /pause 8 root 0:00 nginx: master process nginx -g daemon off; @@ -77,12 +81,18 @@ PID USER TIME COMMAND 23 root 0:00 ps ax ``` -It's even possible to access another container image using the +It's even possible to access the file system of another container using the `/proc/$pid/root` link. +```shell +# run this inside the "shell" container +# change "8" to the PID of the Nginx process, if necessary +head /proc/8/root/etc/nginx/nginx.conf ``` -/ # head /proc/8/root/etc/nginx/nginx.conf +The output is similar to this: + +```none user nginx; worker_processes 1; @@ -94,21 +104,19 @@ events { worker_connections 1024; ``` - - -## Understanding Process Namespace Sharing +## Understanding process namespace sharing Pods share many resources so it makes sense they would also share a process -namespace. Some container images may expect to be isolated from other -containers, though, so it's important to understand these differences: +namespace. Some containers may expect to be isolated from others, though, +so it's important to understand the differences: -1. **The container process no longer has PID 1.** Some container images refuse +1. **The container process no longer has PID 1.** Some containers refuse to start without PID 1 (for example, containers using `systemd`) or run commands like `kill -HUP 1` to signal the container process. In pods with a - shared process namespace, `kill -HUP 1` will signal the pod sandbox. - (`/pause` in the above example.) + shared process namespace, `kill -HUP 1` will signal the pod sandbox + (`/pause` in the above example). 1. **Processes are visible to other containers in the pod.** This includes all information visible in `/proc`, such as passwords that were passed as arguments @@ -118,6 +126,3 @@ containers, though, so it's important to understand these differences: `/proc/$pid/root` link.** This makes debugging easier, but it also means that filesystem secrets are protected only by filesystem permissions. - - - From 614fcc0fd8c3be5485ab3ab2a5166336a90cf45f Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 9 May 2022 09:30:03 +0800 Subject: [PATCH 065/827] Update KMS provider page --- .../tasks/administer-cluster/kms-provider.md | 84 +++++++++++++------ 1 file changed, 58 insertions(+), 26 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/kms-provider.md b/content/en/docs/tasks/administer-cluster/kms-provider.md index 15bc1290ff..d2ea73d761 100644 --- a/content/en/docs/tasks/administer-cluster/kms-provider.md +++ b/content/en/docs/tasks/administer-cluster/kms-provider.md @@ -19,35 +19,50 @@ This page shows how to configure a Key Management Service (KMS) provider and plu -The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS -plugin. The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) as the Kubernetes master(s), is responsible for all communication with the remote KMS. +The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. +The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. +The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. +The KMS provider uses gRPC to communicate with a specific KMS plugin. +The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) +as the Kubernetes control plane, is responsible for all communication with the remote KMS. ## Configuring the KMS provider -To configure a KMS provider on the API server, include a provider of type ```kms``` in the providers array in the encryption configuration file and set the following properties: +To configure a KMS provider on the API server, include a provider of type `kms` in the +`providers` array in the encryption configuration file and set the following properties: * `name`: Display name of the KMS plugin. * `endpoint`: Listen address of the gRPC server (KMS plugin). The endpoint is a UNIX domain socket. * `cachesize`: Number of data encryption keys (DEKs) to be cached in the clear. When cached, DEKs can be used without another call to the KMS; whereas DEKs that are not cached require a call to the KMS to unwrap. -* `timeout`: How long should kube-apiserver wait for kms-plugin to respond before returning an error (default is 3 seconds). +* `timeout`: How long should `kube-apiserver` wait for kms-plugin to respond before + returning an error (default is 3 seconds). -See [Understanding the encryption at rest configuration.](/docs/tasks/administer-cluster/encrypt-data) +See [Understanding the encryption at rest configuration](/docs/tasks/administer-cluster/encrypt-data). ## Implementing a KMS plugin -To implement a KMS plugin, you can develop a new plugin gRPC server or enable a KMS plugin already provided by your cloud provider. You then integrate the plugin with the remote KMS and deploy it on the Kubernetes master. +To implement a KMS plugin, you can develop a new plugin gRPC server or enable a KMS plugin +already provided by your cloud provider. +You then integrate the plugin with the remote KMS and deploy it on the Kubernetes master. ### Enabling the KMS supported by your cloud provider + Refer to your cloud provider for instructions on enabling the cloud provider-specific KMS plugin. ### Developing a KMS plugin gRPC server -You can develop a KMS plugin gRPC server using a stub file available for Go. For other languages, you use a proto file to create a stub file that you can use to develop the gRPC server code. -* Using Go: Use the functions and data structures in the stub file: [service.pb.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.pb.go) to develop the gRPC server code +You can develop a KMS plugin gRPC server using a stub file available for Go. For other languages, +you use a proto file to create a stub file that you can use to develop the gRPC server code. -* Using languages other than Go: Use the protoc compiler with the proto file: [service.proto](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto) to generate a stub file for the specific language +* Using Go: Use the functions and data structures in the stub file: + [service.pb.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.pb.go) + to develop the gRPC server code + +* Using languages other than Go: Use the protoc compiler with the proto file: + [service.proto](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/v1beta1/service.proto) + to generate a stub file for the specific language Then use the functions and data structures in the stub file to develop the server code. @@ -55,7 +70,7 @@ Then use the functions and data structures in the stub file to develop the serve * kms plugin version: `v1beta1` - In response to procedure call Version, a compatible KMS plugin should return v1beta1 as VersionResponse.version. + In response to procedure call Version, a compatible KMS plugin should return `v1beta1` as `VersionResponse.version`. * message version: `v1beta1` @@ -69,12 +84,15 @@ Then use the functions and data structures in the stub file to develop the serve The KMS plugin can communicate with the remote KMS using any protocol supported by the KMS. All configuration data, including authentication credentials the KMS plugin uses to communicate with the remote KMS, -are stored and managed by the KMS plugin independently. The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption. +are stored and managed by the KMS plugin independently. +The KMS plugin can encode the ciphertext with additional metadata that may be required before sending it to the KMS for decryption. ### Deploying the KMS plugin + Ensure that the KMS plugin runs on the same host(s) as the Kubernetes master(s). ## Encrypting your data with the KMS provider + To encrypt the data: 1. Create a new encryption configuration file using the appropriate properties for the `kms` provider: @@ -94,32 +112,43 @@ To encrypt the data: - identity: {} ``` -1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to the location of the configuration file. +1. Set the `--encryption-provider-config` flag on the kube-apiserver to point to + the location of the configuration file. 1. Restart your API server. +For details about the `EncryptionConfiguration` format, please check the +[API server encryption API reference](/docs/reference/config-api/apiserver-encryption.v1/). + ## Verifying that the data is encrypted Data is encrypted when written to etcd. After restarting your `kube-apiserver`, any newly created or updated secret should be encrypted when stored. To verify, you can use the `etcdctl` command line program to retrieve the contents of your secret. -1. Create a new secret called secret1 in the default namespace: - ``` +1. Create a new secret called `secret1` in the `default` namespace: + + ```shell kubectl create secret generic secret1 -n default --from-literal=mykey=mydata ``` -1. Using the etcdctl command line, read that secret out of etcd: - ``` + +1. Using the `etcdctl` command line, read that secret out of etcd: + + ```shell ETCDCTL_API=3 etcdctl get /kubernetes.io/secrets/default/secret1 [...] | hexdump -C ``` - where `[...]` must be the additional arguments for connecting to the etcd server. -1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that the `kms` provider has encrypted the resulting data. + where `[...]` contains the additional arguments for connecting to the etcd server. + +1. Verify the stored secret is prefixed with `k8s:enc:kms:v1:`, which indicates that + the `kms` provider has encrypted the resulting data. 1. Verify that the secret is correctly decrypted when retrieved via the API: - ``` + + ```shell kubectl describe secret secret1 -n default ``` - should match `mykey: mydata` + + The Secret should contain `mykey: mydata` ## Ensuring all secrets are encrypted @@ -129,7 +158,7 @@ The following command reads all secrets and then updates them to apply server si If an error occurs due to a conflicting write, retry the command. For larger clusters, you may wish to subdivide the secrets by namespace or script an update. -``` +```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` @@ -156,12 +185,12 @@ To switch from a local encryption provider to the `kms` provider and re-encrypt secret: ``` -1. Restart all kube-apiserver processes. +1. Restart all `kube-apiserver` processes. 1. Run the following command to force all secrets to be re-encrypted using the `kms` provider. - ``` - kubectl get secrets --all-namespaces -o json| kubectl replace -f - + ```shell + kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` ## Disabling encryption at rest @@ -183,9 +212,12 @@ To disable encryption at rest: endpoint: unix:///tmp/socketfile.sock cachesize: 100 ``` -1. Restart all kube-apiserver processes. + +1. Restart all `kube-apiserver` processes. + 1. Run the following command to force all secrets to be decrypted. - ``` + + ```shell kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` From 6f51f7fee48dc5283dff9318e9f68f5ae424a8f9 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Mon, 30 May 2022 17:43:42 +0900 Subject: [PATCH 066/827] [ko] Update outdated files in dev-1.24-ko.1 M73-M88 --- .../feature-gates.md | 475 +++++++++------ .../docs/reference/glossary/api-eviction.md | 6 +- content/ko/docs/reference/glossary/kubectl.md | 9 +- .../ko/docs/reference/glossary/namespace.md | 4 +- .../reference/glossary/pod-security-policy.md | 3 +- .../reference/issues-security/security.md | 2 - content/ko/docs/reference/kubectl/_index.md | 553 +++++++++++++++++- .../ko/docs/reference/kubectl/cheatsheet.md | 52 +- .../ko/docs/reference/kubectl/conventions.md | 10 + content/ko/docs/reference/kubectl/jsonpath.md | 1 - content/ko/docs/reference/kubectl/overview.md | 547 ----------------- content/ko/docs/reference/tools/_index.md | 3 - content/ko/docs/reference/using-api/_index.md | 5 + .../docs/setup/best-practices/certificates.md | 4 +- .../setup/best-practices/node-conformance.md | 17 +- 15 files changed, 927 insertions(+), 764 deletions(-) delete mode 100644 content/ko/docs/reference/kubectl/overview.md diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 5f31d10efa..b627bdbf19 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -29,7 +29,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다. ```shell ---feature-gates="...,GracefulNodeShutdown=true" +--feature-gates=...,GracefulNodeShutdown=true ``` 다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를 @@ -61,9 +61,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `APIServerIdentity` | `false` | 알파 | 1.20 | | | `APIServerTracing` | `false` | 알파 | 1.22 | | | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | | -| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | | +| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | 1.23 | +| `AnyVolumeDataSource` | `true` | 베타 | 1.24 | | | `AppArmor` | `true` | 베타 | 1.4 | | -| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | | | `CPUManager` | `false` | 알파 | 1.8 | 1.9 | | `CPUManager` | `true` | 베타 | 1.10 | | | `CPUManagerPolicyAlphaOptions` | `false` | 알파 | 1.23 | | @@ -74,34 +74,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CSIInlineVolume` | `true` | 베타 | 1.16 | - | | `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigration` | `true` | 베타 | 1.17 | | -| `CSIMigrationAWS` | `false` | 알파 | 1.14 | | +| `CSIMigrationAWS` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigrationAWS` | `false` | 베타 | 1.17 | 1.22 | | `CSIMigrationAWS` | `true` | 베타 | 1.23 | | -| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | -| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 | -| `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | | | `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 | -| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | | +| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | 1.23 | +| `CSIMigrationAzureFile` | `true` | 베타 | 1.24 | | | `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigrationGCE` | `false` | 베타 | 1.17 | 1.22 | | `CSIMigrationGCE` | `true` | 베타 | 1.23 | | -| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 | -| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | | | `CSIMigrationvSphere` | `false` | 베타 | 1.19 | | | `CSIMigrationPortworx` | `false` | 알파 | 1.23 | | | `csiMigrationRBD` | `false` | 알파 | 1.23 | | -| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 | -| `CSIStorageCapacity` | `true` | 베타 | 1.21 | | | `CSIVolumeHealth` | `false` | 알파 | 1.21 | | -| `CSRDuration` | `true` | 베타 | 1.22 | | -| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 | -| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | | +| `ContextualLogging` | `false` | 알파 | 1.24 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | | `CustomResourceValidationExpressions` | `false` | 알파 | 1.23 | | | `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 | | `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | | -| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 | -| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | | | `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | 1.22 | | `DelegateFSGroupToCSIDriver` | `true` | 베타 | 1.23 | | | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | @@ -111,31 +101,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `DisableCloudProviders` | `false` | 알파 | 1.22 | | | `DisableKubeletCloudCredentialProviders` | `false` | 알파 | 1.23 | | | `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 | -| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | | -| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 | -| `EfficientWatchResumption` | `true` | 베타 | 1.21 | | +| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | 1.21 | +| `DownwardAPIHugePages` | `true` | 베타 | 1.22 | | | `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 | | `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | | | `EphemeralContainers` | `false` | 알파 | 1.16 | 1.22 | | `EphemeralContainers` | `true` | 베타 | 1.23 | | -| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 | -| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | | | `ExpandedDNSConfig` | `false` | 알파 | 1.22 | | -| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 | -| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | | -| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | -| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | | `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 | | `GracefulNodeShutdown` | `true` | 베타 | 1.21 | | -| `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | | -| `GRPCContainerProbe` | `false` | 알파 | 1.23 | | -| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | | +| `GracefulNodeShutdownBasedOnPodPriority` | `false` | 알파 | 1.23 | 1.23 | +| `GracefulNodeShutdownBasedOnPodPriority` | `true` | 베타 | 1.24 | | +| `GRPCContainerProbe` | `false` | 알파 | 1.23 | 1.23 | +| `GRPCContainerProbe` | `true` | 베타 | 1.24 | | +| `HonorPVReclaimPolicy` | `false` | 알파 | 1.23 | | | `HPAContainerMetrics` | `false` | 알파 | 1.20 | | | `HPAScaleToZero` | `false` | 알파 | 1.16 | | -| `IdentifyPodOS` | `false` | 알파 | 1.23 | | -| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 | -| `IndexedJob` | `true` | 베타 | 1.22 | | +| `IdentifyPodOS` | `false` | 알파 | 1.23 | 1.23 | +| `IdentifyPodOS` | `true` | 베타 | 1.24 | | | `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | | | `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | | | `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | | @@ -145,42 +129,44 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `InTreePluginRBDUnregister` | `false` | 알파 | 1.23 | | | `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | | | `JobMutableNodeSchedulingDirectives` | `true` | 베타 | 1.23 | | -| `JobReadyPods` | `false` | 알파 | 1.23 | | +| `JobReadyPods` | `false` | 알파 | 1.23 | 1.23 | +| `JobReadyPods` | `true` | 베타 | 1.24 | | | `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | 1.22 | -| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | | -| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | | +| `JobTrackingWithFinalizers` | `true` | 베타 | 1.23 | 1.23 | +| `JobTrackingWithFinalizers` | `false` | 베타 | 1.24 | | +| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | 1.23 | +| `KubeletCredentialProviders` | `true` | 베타 | 1.24 | | | `KubeletInUserNamespace` | `false` | 알파 | 1.22 | | | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | 1.22 | -| `KubeletPodResourcesGetAllocatable` | `false` | 베타 | 1.23 | | +| `KubeletPodResourcesGetAllocatable` | `true` | 베타 | 1.23 | | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | | `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 | | `LogarithmicScaleDown` | `true` | 베타 | 1.22 | | +| `MaxUnavailableStatefulSet` | `false` | 알파 | 1.24 | | | `MemoryManager` | `false` | 알파 | 1.21 | 1.21 | | `MemoryManager` | `true` | 베타 | 1.22 | | | `MemoryQoS` | `false` | 알파 | 1.22 | | -| `MixedProtocolLBService` | `false` | 알파 | 1.20 | | +| `MinDomainsInPodTopologySpread` | `false` | 알파 | 1.24 | | +| `MixedProtocolLBService` | `false` | 알파 | 1.20 | 1.23 | +| `MixedProtocolLBService` | `true` | 베타 | 1.24 | | | `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 | | `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | | +| `NetworkPolicyStatus` | `false` | 알파 | 1.24 | | | `NodeSwap` | `false` | 알파 | 1.22 | | -| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | -| `NonPreemptingPriority` | `true` | 베타 | 1.19 | | -| `OpenAPIEnums` | `false` | 알파 | 1.23 | | -| `OpenAPIV3` | `false` | 알파 | 1.23 | | +| `NodeOutOfServiceVolumeDetach` | `false` | 알파 | 1.24 | | +| `OpenAPIEnums` | `false` | 알파 | 1.23 | 1.23 | +| `OpenAPIEnums` | `true` | 베타 | 1.24 | | +| `OpenAPIV3` | `false` | 알파 | 1.23 | 1.23 | +| `OpenAPIV3` | `true` | 베타 | 1.24 | | | `PodAndContainerStatsFromCRI` | `false` | 알파 | 1.23 | | -| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 | -| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | | | `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 | | `PodDeletionCost` | `true` | 베타 | 1.22 | | -| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | -| `PodOverhead` | `true` | 베타 | 1.18 | | | `PodSecurity` | `false` | 알파 | 1.22 | 1.22 | | `PodSecurity` | `true` | 베타 | 1.23 | | -| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 | -| `PreferNominatedNode` | `true` | 베타 | 1.22 | | | `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 | | `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | | | `ProcMountType` | `false` | 알파 | 1.12 | | @@ -190,17 +176,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `RecoverVolumeExpansionFailure` | `false` | 알파 | 1.23 | | | `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 | | `RemainingItemCount` | `true` | 베타 | 1.16 | | -| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 | -| `RemoveSelfLink` | `true` | 베타 | 1.20 | | | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | | `SeccompDefault` | `false` | 알파 | 1.22 | | +| `ServerSideFieldValidation` | `false` | 알파 | 1.23 | - | | `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 | | `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | | -| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 | -| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | | -| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 | -| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | | +| `ServiceIPStaticSubrange` | `false` | 알파 | 1.24 | | | `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 | | `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | | | `StatefulSetAutoDeletePVC` | `false` | 알파 | 1.22 | | @@ -209,10 +191,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `StorageVersionAPI` | `false` | 알파 | 1.20 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | -| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 | -| `SuspendJob` | `true` | 베타 | 1.22 | | | `TopologyAwareHints` | `false` | 알파 | 1.21 | 1.22 | -| `TopologyAwareHints` | `false` | 베타 | 1.23 | | +| `TopologyAwareHints` | `false` | 베타 | 1.23 | 1.23 | +| `TopologyAwareHints` | `true` | 베타 | 1.24 | | | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 | | `TopologyManager` | `true` | 베타 | 1.18 | | | `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - | @@ -220,7 +201,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `WinOverlay` | `false` | 알파 | 1.14 | 1.19 | | `WinOverlay` | `true` | 베타 | 1.20 | | | `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | 1.22 | -| `WindowsHostProcessContainers` | `false` | 베타 | 1.23 | | +| `WindowsHostProcessContainers` | `true` | 베타 | 1.23 | | {{< /table >}} ### GA 또는 사용 중단된 기능을 위한 기능 게이트 @@ -230,19 +211,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | 기능 | 디폴트 | 단계 | 도입 | 종료 | |---------|---------|-------|-------|-------| | `Accelerators` | `false` | 알파 | 1.6 | 1.10 | -| `Accelerators` | - | 사용중단 | 1.11 | - | +| `Accelerators` | - | Deprecated | 1.11 | - | | `AdvancedAuditing` | `false` | 알파 | 1.7 | 1.7 | | `AdvancedAuditing` | `true` | 베타 | 1.8 | 1.11 | | `AdvancedAuditing` | `true` | GA | 1.12 | - | | `AffinityInAnnotations` | `false` | 알파 | 1.6 | 1.7 | -| `AffinityInAnnotations` | - | 사용중단 | 1.8 | - | +| `AffinityInAnnotations` | - | Deprecated | 1.8 | - | | `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 | | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | | `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | | `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | | `AttachVolumeLimit` | `true` | GA | 1.17 | - | | `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 | -| `BalanceAttachedNodeVolumes` | `false` | 사용중단 | 1.22 | | +| `BalanceAttachedNodeVolumes` | `false` | Deprecated | 1.22 | | | `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | | `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | | `BlockVolume` | `true` | GA | 1.18 | - | @@ -251,7 +232,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - | | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 | | `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 | -| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | | +| `ConfigurableFSGroupPolicy` | `true` | GA | 1.23 | - | +| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 | +| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | 1.23 | +| `ControllerManagerLeaderMigration` | `true` | GA | 1.24 | - | | `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | | `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 | | `CRIContainerLogRotation` | `true` | GA | 1.21 | - | @@ -260,34 +244,47 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CSIBlockVolume` | `true` | GA | 1.18 | - | | `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | | `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | -| `CSIDriverRegistry` | `true` | GA | 1.18 | | +| `CSIDriverRegistry` | `true` | GA | 1.18 | - | | `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAWSComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationAWSComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | +| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | 1.22 | +| `CSIMigrationAzureDisk` | `true` | 베타 | 1.23 | 1.23 | +| `CSIMigrationAzureDisk` | `true` | GA | 1.24 | | | `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAzureDiskComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationAzureDiskComplete` | - | Deprecated | 1.21 | - | | `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationAzureFileComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationAzureFileComplete` | - | Deprecated | 1.21 | - | | `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationGCEComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationGCEComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 | +| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | 1.23 | +| `CSIMigrationOpenStack` | `true` | GA | 1.24 | | | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 | -| `CSIMigrationOpenStackComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationOpenStackComplete` | - | Deprecated | 1.21 | - | | `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 | -| `CSIMigrationvSphereComplete` | - | 사용중단 | 1.22 | - | +| `CSIMigrationvSphereComplete` | - | Deprecated | 1.22 | - | | `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 | | `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 | -| `CSINodeInfo` | `true` | GA | 1.17 | | +| `CSINodeInfo` | `true` | GA | 1.17 | - | | `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 | | `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 | | `CSIPersistentVolume` | `true` | GA | 1.13 | - | | `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 | | `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 | -| `CSIServiceAccountToken` | `true` | GA | 1.22 | | +| `CSIServiceAccountToken` | `true` | GA | 1.22 | - | +| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 | +| `CSIStorageCapacity` | `true` | 베타 | 1.21 | 1.23 | +| `CSIStorageCapacity` | `true` | GA | 1.24 | - | | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 | | `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | 1.22 | | `CSIVolumeFSGroupPolicy` | `true` | GA | 1.23 | | +| `CSRDuration` | `true` | 베타 | 1.22 | 1.23 | +| `CSRDuration` | `true` | GA | 1.24 | - | | `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | | `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 | | `CronJobControllerV2` | `true` | GA | 1.22 | - | +| `CronJobTimeZone` | `false` | 알파 | 1.24 | | | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | | `CustomPodDNS` | `true` | GA | 1.14 | - | @@ -306,25 +303,31 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `CustomResourceWebhookConversion` | `false` | 알파 | 1.13 | 1.14 | | `CustomResourceWebhookConversion` | `true` | 베타 | 1.15 | 1.15 | | `CustomResourceWebhookConversion` | `true` | GA | 1.16 | - | +| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 | +| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | 1.23 | +| `DefaultPodTopologySpread` | `true` | GA | 1.24 | - | | `DryRun` | `false` | 알파 | 1.12 | 1.12 | | `DryRun` | `true` | 베타 | 1.13 | 1.18 | | `DryRun` | `true` | GA | 1.19 | - | | `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 | -| `DynamicAuditing` | - | 사용중단 | 1.19 | - | +| `DynamicAuditing` | - | Deprecated | 1.19 | - | | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 | -| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - | +| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - | | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | -| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - | +| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - | | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | -| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - | +| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 | +| `EfficientWatchResumption` | `true` | 베타 | 1.21 | 1.23 | +| `EfficientWatchResumption` | `true` | GA | 1.24 | - | +| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | -| `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - | +| `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - | | `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | | `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 | | `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 | -| `EndpointSlice` | `true` | GA | 1.21 | - | +| `EndpointSlice` | `true` | GA | 1.21 | - | | `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 | | `EndpointSliceNodeName` | `true` | GA | 1.21 | - | | `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 | @@ -334,8 +337,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | +| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 | +| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | 1.23 | +| `ExpandCSIVolumes` | `true` | GA | 1.24 | - | +| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 | +| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | 1.23 | +| `ExpandInUsePersistentVolumes` | `true` | GA | 1.24 | - | +| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | +| `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | 1.23 | +| `ExpandPersistentVolumes` | `true` | GA | 1.24 |- | | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | -| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - | +| `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - | | `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | @@ -349,47 +361,60 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `HugePages` | `true` | 베타| 1.10 | 1.13 | | `HugePages` | `true` | GA | 1.14 | - | | `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 | -| `HyperVContainer` | `false` | 사용중단 | 1.20 | - | +| `HyperVContainer` | `false` | Deprecated | 1.20 | - | +| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | +| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 | +| `IPv6DualStack` | `true` | GA | 1.23 | - | | `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | | `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 | | `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | | +| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 | +| `IndexedJob` | `true` | 베타 | 1.22 | 1.23 | +| `IndexedJob` | `true` | GA | 1.24 | - | | `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 | | `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | 1.22 | | `IngressClassNamespacedParams` | `true` | GA | 1.23 | - | | `Initializers` | `false` | 알파 | 1.7 | 1.13 | -| `Initializers` | - | 사용중단 | 1.14 | - | -| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | -| `IPv6DualStack` | `true` | 베타 | 1.21 | 1.22 | -| `IPv6DualStack` | `true` | GA | 1.23 | - | +| `Initializers` | - | Deprecated | 1.14 | - | | `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | -| `KubeletConfigFile` | - | 사용중단 | 1.10 | - | +| `KubeletConfigFile` | - | Deprecated | 1.10 | - | | `KubeletPluginsWatcher` | `false` | 알파 | 1.11 | 1.11 | | `KubeletPluginsWatcher` | `true` | 베타 | 1.12 | 1.12 | | `KubeletPluginsWatcher` | `true` | GA | 1.13 | - | | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | | `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | +| `LegacyServiceAccountTokenNoAutoGeneration` | `true` | 베타 | 1.24 | | | `MountContainers` | `false` | 알파 | 1.9 | 1.16 | -| `MountContainers` | `false` | 사용중단 | 1.17 | - | +| `MountContainers` | `false` | Deprecated | 1.17 | - | | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | +| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 | +| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - | | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | | `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | | `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | | `NodeLease` | `false` | 알파 | 1.12 | 1.13 | | `NodeLease` | `true` | 베타 | 1.14 | 1.16 | | `NodeLease` | `true` | GA | 1.17 | - | -| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 | -| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - | +| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | +| `NonPreemptingPriority` | `true` | 베타 | 1.19 | 1.23 | +| `NonPreemptingPriority` | `true` | GA | 1.24 | - | | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | -| `PVCProtection` | - | 사용중단 | 1.10 | - | +| `PVCProtection` | - | Deprecated | 1.10 | - | | `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | | `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | | `PersistentLocalVolumes` | `true` | GA | 1.14 | - | +| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 | +| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | 1.23 | +| `PodAffinityNamespaceSelector` | `true` | GA | 1.24 | - | | `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | | `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 | | `PodDisruptionBudget` | `true` | GA | 1.21 | - | +| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | +| `PodOverhead` | `true` | 베타 | 1.18 | 1.23 | +| `PodOverhead` | `true` | GA | 1.24 | - | | `PodPriority` | `false` | 알파 | 1.8 | 1.10 | | `PodPriority` | `true` | 베타 | 1.11 | 1.13 | | `PodPriority` | `true` | GA | 1.14 | - | @@ -399,10 +424,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `PodShareProcessNamespace` | `false` | 알파 | 1.10 | 1.11 | | `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 | | `PodShareProcessNamespace` | `true` | GA | 1.17 | - | +| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 | +| `PreferNominatedNode` | `true` | 베타 | 1.22 | 1.23 | +| `PreferNominatedNode` | `true` | GA | 1.24 | - | +| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 | +| `RemoveSelfLink` | `true` | 베타 | 1.20 | 1.23 | +| `RemoveSelfLink` | `true` | GA | 1.24 | - | | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | -| `RequestManagement` | - | 사용중단 | 1.17 | - | +| `RequestManagement` | - | Deprecated | 1.17 | - | | `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 | -| `ResourceLimitsPriorityFunction` | - | 사용중단 | 1.19 | - | +| `ResourceLimitsPriorityFunction` | - | Deprecated | 1.19 | - | | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | @@ -434,6 +465,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | | `ServiceAppProtocol` | `true` | 베타 | 1.19 | 1.19 | | `ServiceAppProtocol` | `true` | GA | 1.20 | - | +| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 | +| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | 1.23 | +| `ServiceLBNodePortControl` | `true` | GA | 1.24 | - | +| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 | +| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | 1.23 | +| `ServiceLoadBalancerClass` | `true` | GA | 1.24 | - | | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | @@ -441,7 +478,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | | `ServiceNodeExclusion` | `true` | GA | 1.21 | - | | `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 | -| `ServiceTopology` | `false` | 사용중단 | 1.20 | - | +| `ServiceTopology` | `false` | Deprecated | 1.20 | - | | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 | | `SetHostnameAsFQDN` | `true` | GA | 1.22 | - | @@ -452,8 +489,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | | `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 | -| `StreamingProxyRedirects` | `true` | 사용중단 | 1.18 | 1.21 | -| `StreamingProxyRedirects` | `false` | 사용중단 | 1.22 | - | +| `StreamingProxyRedirects` | `true` | Deprecated | 1.18 | 1.21 | +| `StreamingProxyRedirects` | `false` | Deprecated | 1.22 | - | | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | @@ -464,8 +501,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | | `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 | | `SupportPodPidsLimit` | `true` | GA | 1.20 | - | +| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 | +| `SuspendJob` | `true` | 베타 | 1.22 | 1.23 | +| `SuspendJob` | `true` | GA | 1.24 | - | | `Sysctls` | `true` | 베타 | 1.11 | 1.20 | -| `Sysctls` | `true` | GA | 1.21 | | +| `Sysctls` | `true` | GA | 1.21 | - | | `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | | `TTLAfterFinished` | `true` | 베타 | 1.21 | 1.22 | | `TTLAfterFinished` | `true` | GA | 1.23 | - | @@ -483,7 +523,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, | `TokenRequestProjection` | `true` | GA | 1.20 | - | | `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 | -| `ValidateProxyRedirects` | `true` | 사용중단 | 1.22 | - | +| `ValidateProxyRedirects` | `true` | Deprecated | 1.22 | - | | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | | `VolumePVCDataSource` | `true` | GA | 1.18 | - | @@ -579,48 +619,58 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다. - `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에 대한 제한을 보고하도록 한다. - 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 참고한다. + 자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을 + 참고한다. - `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를 포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가 더 가까운 노드가 선호된다. - `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다. 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. -- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 - 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 - `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. - 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 - 확인한다. +- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 + 서비스어카운트 볼륨을 마이그레이션한다. + 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 + 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. + 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 + `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. + 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가 kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면, cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록 - [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의 + [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 + [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의 리더 마이그레이션(Leader Migration)을 활성화한다. - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. -- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 미세 조정을 허용한다. +- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의 + 미세 조정을 허용한다. 이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다. 이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다. -- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 미세 조정을 허용한다. +- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의 + 미세 조정을 허용한다. 이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다. 이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다. - `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다. -- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며, -컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다. -더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. +- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. + 로그 파일 사이즈 기본값은 10MB이며, + 컨테이너 당 최대 로그 파일 수 기본값은 5이다. + 이 값은 kubelet 환경설정으로 변경할 수 있다. + 더 자세한 내용은 + [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. - 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) - 문서를 참고한다. + 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을 + 참고한다. - `CSIDriverRegistry`: csi.storage.k8s.io에서 CSIDriver API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다. - `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서 사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다. -- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 - AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 노드에 - EBS CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 EBS 플러그인으로 - 폴백(falling back)을 지원한다. CSIMigration 기능 플래그가 필요하다. +- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을 + AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. - `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. @@ -630,21 +680,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 더 이상 사용되지 않는다. - `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. - 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 - AzureDisk 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 - 필요하다. -- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 Azure-Disk 인-트리 - 플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 - Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 - 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 - 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 - 있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 - 더 이상 사용되지 않는다. + 이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. +- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서 + Azure-Disk 인-트리 플러그인 등록을 중지하고 + shim 및 변환 로직을 사용하여 + 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. + 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 + AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 + `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. - 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 - AzureFile 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 - 필요하다. + 이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 @@ -654,46 +709,57 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, `InTreePluginAzureFileUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 - GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 - PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 - 지원한다. CSIMigration 기능 플래그가 필요하다. -- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 - Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. - 클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, - Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. - 이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 - `InTreePluginRBDUnregister` 기능 플래그에 의해 - 사용 중단되었다. + GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI - 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 + 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 - Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 - Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 - Cinder 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. + Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. + 이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 - Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 + Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. +- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 + Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. + 클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고, + Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다. + 이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해 + 사용 중단되었다. - `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. - 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 - 인-트리 vSphere 플러그인으로 폴백을 지원한다. CSIMigration 기능 플래그가 필요하다. + 이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해 + 인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다. + 프로비전 동작에 대해서는 폴백을 지원하지 않는데, + 프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다. + 이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다. - `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 - 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 + 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다. - `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을 Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. - Portworx CSI 드라이버가 설치 및 설정되어 있어야 하며, kube-controller-manager와 kubelet 환경 설정 내에 `CSIMigrationPortworx=true` 기능 게이트가 활성화되어 있어야 한다. -- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. + Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다. +- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 마운트할 수 있다. @@ -714,14 +780,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. +- `ContextualLogging`: 이 기능을 활성화하면, + 컨텍스츄얼 로깅을 지원하는 쿠버네티스 구성 요소가 로그 출력에 추가 상세를 추가한다. - `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에 대한 리더 마이그레이션을 지원한다. - `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면, 동일한 컨트롤러의 버전 1이 선택된다. +- `CronJobTimeZone`: [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)의 선택적 `timeZone` 필드 사용을 허용한다. - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서 `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다. -- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 검증 규칙을 기반으로 커스텀 리소스를 검증하는 표현 언어 검증(expression language validation)을 CRD에 활성화한다. +- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된 + 검증 규칙을 기반으로 커스텀 리소스를 검증하는 + 표현 언어 검증(expression language validation)을 CRD에 활성화한다. - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. 자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을 확인한다. @@ -755,8 +826,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. - `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다. -- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. - [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다. +- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. + 이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다. + 이 기능 게이트는 1.24에 kubelet에서 제거되었다. [kubelet 재구성하기](/docs/tasks/administer-cluster/reconfigure-kubelet/)를 참고한다. - `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다. 이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다. @@ -804,7 +876,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. -- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다. +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 + 버그를 수정한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 @@ -817,8 +890,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 참조한다. - `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때 kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다. -- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다. +- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다. + [활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다. - `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다. + 더 자세한 정보는 + [퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer)](/ko/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) 문서를 + 참고한다. - `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의 개별 컨테이너 메트릭을 기반으로 확장한다. - `HPAScaleToZero`: 사용자 정의 또는 외부 메트릭을 사용할 때 `HorizontalPodAutoscaler` 리소스에 대해 @@ -830,10 +907,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. -- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. - 쿠버네티스 {{< skew currentVersion >}}에서, `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다. +- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다. + 이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다. + 쿠버네티스 {{< skew currentVersion >}}에서, + `pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다. - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. +- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를 + 완료 인덱스에 따라 관리할 수 있도록 허용한다. +- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가 + `IngressClass` 리소스를 참조할 수 있도록 허용한다. + 이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다. +- `Initializers`: Initializers 어드미션 플러그인을 사용하여, + 오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다. - `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 플러그인의 등록을 중지한다. - `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 @@ -850,13 +936,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 플러그인의 등록을 중지한다. - `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 플러그인의 등록을 중지한다. -- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 - 완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다. -- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로 - 한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에 - `Scope` 와 `Namespace` 2개의 필드를 추가한다. -- `Initializers`: Initializers 어드미션 플러그인을 사용하여 오브젝트 생성의 - 비동기 조정을 허용한다. - `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) 기능을 활성화한다. - `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의 @@ -874,20 +953,26 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, kubelet 구성을 로드할 수 있다. 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다. -- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다. -- `KubeletInUserNamespace`: {{}}에서 kubelet 실행을 활성화한다. +- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 + kubelet exec 자격 증명 공급자를 활성화한다. +- `KubeletInUserNamespace`: {{}}에서 + kubelet 실행을 활성화한다. [루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다. - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을 참고한다. -- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다. - 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를 +- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 + `GetAllocatableResources` 기능을 활성화한다. + 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, + 할당 가능 자원에 대한 정보를 [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다. - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. +- `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반 + [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 자동 생성을 중단한다. - `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 @@ -901,20 +986,34 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 향상시킨다. - `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여 축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다. +- `MaxUnavailableStatefulSet`: 스테이트풀셋의 + [롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해 + `maxUnavailable` 필드를 설정할 수 있도록 한다. + 이 필드는 업데이트 동안 사용 불가능(unavailable) 상태의 파드를 몇 개까지 허용할지를 정한다. - `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한 메모리 어피니티를 설정할 수 있다. -- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. +- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 + 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. +- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/) 내의 + `minDomains` 사용을 활성화한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. - `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) - {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가) -- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. + {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. + (네임스페이스의 이름도 변경 불가) +- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 + 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. +- `NetworkPolicyStatus`: 네트워크폴리시 오브젝트에 대해 `status` 서브리소스를 활성화한다. - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. +- `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면, + 노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며, + 종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다. + 이로 인해 삭제된 파드가 다른 노드에서 빠르게 복구될 수 있다. - `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다. 반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다. 더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다. @@ -922,8 +1021,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의 "enum" 필드 채우기를 활성화한다. - `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다. -- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 - 삭제되지 않도록 한다. - `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록, [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다. - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. @@ -931,8 +1028,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라 CRI 컨테이너 런타임으로부터 수집하도록 설정한다. - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. -- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 - [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다. +- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) + 기능과 + [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) + 쿼터 범위 기능을 활성화한다. - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. - `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 @@ -948,12 +1047,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 지정된 노드를 먼저 검사할지 여부를 스케줄러에 알려준다. - `ProbeTerminationGracePeriod`: 파드의 [프로브-수준 - `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다. + `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) + 기능을 활성화한다. 더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다. - `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여 컨테이너의 proc 타입의 마운트를 제어할 수 있다. - `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록 kube-proxy를 활성화한다. +- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 + 삭제되지 않도록 한다. - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다 (현재 메모리만 해당). @@ -966,8 +1068,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `RemainingItemCount`: API 서버가 [청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한 응답에서 남은 항목 수를 표시하도록 허용한다. -- `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고 - 제거한다. +- `RemoveSelfLink`: 모든 오브젝트와 콜렉션에 대해 `.metadata.selfLink` 필드를 빈 칸(빈 문자열)으로 설정한다. + 이 필드는 쿠버네티스 v1.16에서 사용 중단되었다. + 이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만, + 항상 빈 칸으로 유지된다. - `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을 관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다. - `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 @@ -982,7 +1086,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 참조한다. - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. - 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. + 자세한 내용은 + [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. 자세한 사항은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다. @@ -994,12 +1099,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 스케줄링할 수 있다. - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. -- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다. +- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 + `RuntimeDefault`을 사용한다. seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다. - `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여 목록 작업을 가속화할 수 있다. - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다. +- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다. + 이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라 + API 서버 사이드에서 수행됨을 의미한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 @@ -1007,7 +1116,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다. - `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다. - `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다. -- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은 +- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. + 자세한 내용은 [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 @@ -1017,6 +1127,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. +- `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는 + 서비스 ClusterIP 할당 전략을 활성화한다. + ClusterIP 동적 할당을 주로 상위 범위에서 수행하여, + 사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다. + 더 자세한 사항은 + [충돌 방지](/ko/docs/concepts/services-networking/service/#avoiding-collisions)를 참고한다. - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다. @@ -1103,3 +1219,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, * [사용 중단 정책](/docs/reference/using-api/deprecation-policy/)은 쿠버네티스에 대한 기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다. +* 쿠버네티스 1.24부터, 새로운 베타 API는 기본적으로 활성화되어 있지 않다. + 베타 기능을 활성화하려면, 연관된 API 리소스도 활성화해야 한다. + 예를 들어, `storage.k8s.io/v1beta1/csistoragecapacities`와 같은 특정 리소스를 활성화하려면, + `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`를 설정한다. + 명령줄 플래그에 대한 상세 사항은 [API 버전 규칙](/ko/docs/reference/using-api/#api-버전-규칙)을 참고한다. diff --git a/content/ko/docs/reference/glossary/api-eviction.md b/content/ko/docs/reference/glossary/api-eviction.md index 7d5ee60667..d155f0152a 100644 --- a/content/ko/docs/reference/glossary/api-eviction.md +++ b/content/ko/docs/reference/glossary/api-eviction.md @@ -10,7 +10,6 @@ aka: tags: - operation --- - API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core)를 사용하여 생성된 `Eviction` 오브젝트로 파드를 정상 종료한다. @@ -20,4 +19,9 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api 축출 API를 직접 호출해 축출 요청을 할 수 있다. `Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다. +API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 +[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다. + API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다. + +* 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다. diff --git a/content/ko/docs/reference/glossary/kubectl.md b/content/ko/docs/reference/glossary/kubectl.md index 0de6f95898..fadfb2b275 100644 --- a/content/ko/docs/reference/glossary/kubectl.md +++ b/content/ko/docs/reference/glossary/kubectl.md @@ -4,16 +4,19 @@ id: kubectl date: 2018-04-12 full_link: /docs/user-guide/kubectl-overview/ short_description: > - 쿠버네티스 API 서버와 통신하기 위한 커맨드라인 툴. + 쿠버네티스 클러스터와 통신하기 위한 커맨드라인 툴. aka: +- kubectl tags: - tool - fundamental --- - {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} 서버와 통신하기 위한 커맨드라인 툴. +쿠버네티스 API를 사용하여 +쿠버네티스 클러스터의 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}과 +통신하기 위한 커맨드라인 툴 -사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl를 사용할 수 있다. +사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 `kubectl`을 사용할 수 있다. diff --git a/content/ko/docs/reference/glossary/namespace.md b/content/ko/docs/reference/glossary/namespace.md index 417ad0672f..3c98d7a7a7 100644 --- a/content/ko/docs/reference/glossary/namespace.md +++ b/content/ko/docs/reference/glossary/namespace.md @@ -2,9 +2,9 @@ title: 네임스페이스(Namespace) id: namespace date: 2018-04-12 -full_link: /ko/docs/concepts/overview/working-with-objects/namespaces +full_link: /ko/docs/concepts/overview/working-with-objects/namespaces/ short_description: > - 쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. + 쿠버네티스에서, 하나의 클러스터 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상화. aka: tags: diff --git a/content/ko/docs/reference/glossary/pod-security-policy.md b/content/ko/docs/reference/glossary/pod-security-policy.md index 4ef734d946..8dd0a09af4 100644 --- a/content/ko/docs/reference/glossary/pod-security-policy.md +++ b/content/ko/docs/reference/glossary/pod-security-policy.md @@ -2,7 +2,7 @@ title: 파드 시큐리티 폴리시(Pod Security Policy) id: pod-security-policy date: 2018-04-12 -full_link: /ko/docs/concepts/policy/pod-security-policy/ +full_link: /ko/docs/concepts/security/pod-security-policy/ short_description: > 파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다. @@ -17,3 +17,4 @@ tags: 파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다. +파드 시큐리티 폴리시는 쿠버네티스 v1.21에서 사용 중단되었고, v1.25에서 제거될 예정이다. [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 또는 써드파티 어드미션 플러그인으로 이전(migrate)하는 것을 추천한다. diff --git a/content/ko/docs/reference/issues-security/security.md b/content/ko/docs/reference/issues-security/security.md index 2c5a287df4..84fda49478 100644 --- a/content/ko/docs/reference/issues-security/security.md +++ b/content/ko/docs/reference/issues-security/security.md @@ -19,8 +19,6 @@ weight: 20 보안 및 주요 API 공지에 대한 이메일을 위해서는 [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce)) 그룹에 가입한다. -[이 링크](https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50)를 사용하여 RSS 피드도 구독할 수 있다. - ## 취약점 보고 우리는 쿠버네티스 오픈소스 커뮤니티에 취약점을 보고하는 보안 연구원들과 사용자들에게 매우 감사하고 있다. 모든 보고서는 커뮤니티 자원 봉사자들에 의해 철저히 조사된다. diff --git a/content/ko/docs/reference/kubectl/_index.md b/content/ko/docs/reference/kubectl/_index.md index 765adb6fe8..a649fb2045 100644 --- a/content/ko/docs/reference/kubectl/_index.md +++ b/content/ko/docs/reference/kubectl/_index.md @@ -1,5 +1,556 @@ --- -title: "kubectl" +title: 명령줄 도구 (kubectl) +content_type: reference weight: 60 +no_list: true +card: + name: reference + weight: 20 --- + +{{< glossary_definition prepend="쿠버네티스는 다음을 제공한다: " term_id="kubectl" length="short" >}} + +이 툴의 이름은 `kubectl`이다. + +구성을 위해, `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. +KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +파일을 지정할 수 있다. + +이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. +지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 +[kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. + +설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/)를 참고하고, +빠른 가이드는 [치트 시트](/ko/docs/reference/kubectl/cheatsheet/)를 참고한다. `docker` 명령줄 도구에 익숙하다면, +[도커 사용자를 위한 `kubectl`](/ko/docs/reference/kubectl/docker-cli-to-kubectl/)에서 대응되는 쿠버네티스 명령어를 볼 수 있다. + + + +## 구문 + +터미널 창에서 `kubectl` 명령을 실행하려면 다음의 구문을 사용한다. + +```shell +kubectl [command] [TYPE] [NAME] [flags] +``` + +다음은 `command`, `TYPE`, `NAME` 과 `flags` 에 대한 설명이다. + +* `command`: 하나 이상의 리소스에서 수행하려는 동작을 지정한다. +예: `create`, `get`, `describe`, `delete` + +* `TYPE`: [리소스 타입](#리소스-타입)을 지정한다. 리소스 타입은 대소문자를 구분하지 않으며 + 단수형, 복수형 또는 약어 형식을 지정할 수 있다. + 예를 들어, 다음의 명령은 동일한 출력 결과를 생성한다. + + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` + +* `NAME`: 리소스 이름을 지정한다. 이름은 대소문자를 구분한다. 이름을 생략하면, 모든 리소스에 대한 세부 사항이 표시된다. 예: `kubectl get pods` + + 여러 리소스에 대한 작업을 수행할 때, 타입 및 이름별로 각 리소스를 지정하거나 하나 이상의 파일을 지정할 수 있다. + + * 타입 및 이름으로 리소스를 지정하려면 다음을 참고한다. + + * 리소스가 모두 동일한 타입인 경우 리소스를 그룹화하려면 다음을 사용한다. `TYPE1 name1 name2 name<#>`
+ 예: `kubectl get pod example-pod1 example-pod2` + + * 여러 리소스 타입을 개별적으로 지정하려면 다음을 사용한다. `TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`
+ 예: `kubectl get pod/example-pod1 replicationcontroller/example-rc1` + + * 하나 이상의 파일로 리소스를 지정하려면 다음을 사용한다. `-f file1 -f file2 -f file<#>` + + * YAML이 특히 구성 파일에 대해 더 사용자 친화적이므로, [JSON 대신 YAML을 사용한다](/ko/docs/concepts/configuration/overview/#일반적인-구성-팁).
+ 예: `kubectl get -f ./pod.yaml` + +* `flags`: 선택적 플래그를 지정한다. 예를 들어, `-s` 또는 `--server` 플래그를 사용하여 쿠버네티스 API 서버의 주소와 포트를 지정할 수 있다.
+ +{{< caution >}} +커맨드 라인에서 지정하는 플래그는 기본값과 해당 환경 변수를 무시한다. +{{< /caution >}} + +도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다. + +## 클러스터 내 인증과 네임스페이스 오버라이드 + +기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다. + +하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다. + +**`POD_NAMESPACE` 환경 변수** + +`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다. + +명시적으로 `--namespace ` 인자를 사용하면 위와 같은 동작을 오버라이드한다. + +**kubectl이 서비스어카운트 토큰을 관리하는 방법** + +만약 +* 쿠버네티스 서비스 어카운트 토큰 파일이 + `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고, +* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고, +* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고, +* kubectl 명령에 네임스페이스를 명시하지 않으면 + +kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다. +kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다. +이는 클러스터 외부에서 실행되었을 때와는 다른데, +kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우 +kubectl은 `default` 네임스페이스에 대해 동작한다. + +## 명령어 + +다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다. + +명령어 | 구문 | 설명 +-------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 쿠버네티스 클러스터에서 기본적으로 활성화되어 있지 않은 알파 기능의 사용할 수 있는 명령을 나열한다. +`annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 하나 이상의 리소스 어노테이션을 추가하거나 업데이트한다. +`api-resources` | `kubectl api-resources [flags]` | 사용 가능한 API 리소스를 나열한다. +`api-versions` | `kubectl api-versions [flags]` | 사용 가능한 API 버전을 나열한다. +`apply` | `kubectl apply -f FILENAME [flags]`| 파일이나 표준입력(stdin)으로부터 리소스에 구성 변경 사항을 적용한다. +`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 실행 중인 컨테이너에 연결하여 출력 스트림을 보거나 표준입력을 통해 컨테이너와 상호 작용한다. +`auth` | `kubectl auth [flags] [options]` | 승인을 검사한다. +`autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 레플리케이션 컨트롤러에서 관리하는 파드 집합을 자동으로 조정한다. +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 인증서 리소스를 수정한다. +`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다. +`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다. +`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다. +`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다. +`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다. +`cp` | `kubectl cp [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다. +`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다. +`delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | 파일, 표준입력 또는 레이블 셀렉터, 이름, 리소스 셀렉터 또는 리소스를 지정하여 리소스를 삭제한다. +`describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 하나 이상의 리소스의 자세한 상태를 표시한다. +`diff` | `kubectl diff -f FILENAME [flags]`| 라이브 구성에 대해 파일이나 표준입력의 차이점을 출력한다. +`drain` | `kubectl drain NODE [options]` | 유지 보수를 준비 중인 노드를 드레인한다. +`edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 기본 편집기를 사용하여 서버에서 하나 이상의 리소스 정의를 편집하고 업데이트한다. +`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 파드의 컨테이너에 대해 명령을 실행한다. +`explain` | `kubectl explain [--recursive=false] [flags]` | 파드, 노드, 서비스 등의 다양한 리소스에 대한 문서를 출력한다. +`expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 레플리케이션 컨트롤러, 서비스 또는 파드를 새로운 쿠버네티스 서비스로 노출한다. +`get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 하나 이상의 리소스를 나열한다. +`kustomize` | `kubectl kustomize [flags] [options]` | kustomization.yaml 파일의 지시 사항에서 생성된 API 리소스 집합을 나열한다. 인수는 파일을 포함하는 디렉터리의 경로이거나, 리포지터리 루트와 관련하여 경로 접미사가 동일한 git 리포지터리 URL이어야 한다. +`label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 하나 이상의 리소스 레이블을 추가하거나 업데이트한다. +`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 파드의 컨테이너에 대한 로그를 출력한다. +`options` | `kubectl options` | 모든 명령에 적용되는 전역 커맨드 라인 옵션을 나열한다. +`patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | 전략적 병합 패치 프로세스를 사용하여 리소스의 하나 이상의 필드를 업데이트한다. +`plugin` | `kubectl plugin [flags] [options]` | 플러그인과 상호 작용하기 위한 유틸리티를 제공한다. +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 하나 이상의 로컬 포트를 파드로 전달한다. +`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 쿠버네티스 API 서버에 프록시를 실행한다. +`replace` | `kubectl replace -f FILENAME` | 파일 또는 표준입력에서 리소스를 교체한다. +`rollout` | `kubectl rollout SUBCOMMAND [options]` | 리소스의 롤아웃을 관리한다. 유효한 리소스 타입에는 디플로이먼트(deployment), 데몬셋(daemonset)과 스테이트풀셋(statefulset)이 포함된다. +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] | 클러스터에서 지정된 이미지를 실행한다. +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 지정된 레플리케이션 컨트롤러의 크기를 업데이트한다. +`set` | `kubectl set SUBCOMMAND [options]` | 애플리케이션 리소스를 구성한다. +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 하나 이상의 노드에서 테인트(taint)를 업데이트한다. +`top` | `kubectl top [flags] [options]` | 리소스(CPU/메모리/스토리지) 사용량을 표시한다. +`uncordon` | `kubectl uncordon NODE [options]` | 노드를 스케줄 가능(schedulable)으로 표시한다. +`version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. + +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. + +## 리소스 타입 + +다음 표에는 지원되는 모든 리소스 타입과 해당 약어가 나열되어 있다. + +(이 출력은 `kubectl api-resources` 에서 확인할 수 있으며, 쿠버네티스 1.19.1 에서의 출력을 기준으로 한다.) + +| NAME | SHORTNAMES | APIGROUP | NAMESPACED | KIND | +|---|---|---|---|---| +| `bindings` | | | true | Binding | +| `componentstatuses` | `cs` | | false | ComponentStatus | +| `configmaps` | `cm` | | true | ConfigMap | +| `endpoints` | `ep` | | true | Endpoints | +| `events` | `ev` | | true | Event | +| `limitranges` | `limits` | | true | LimitRange | +| `namespaces` | `ns` | | false | Namespace | +| `nodes` | `no` | | false | Node | +| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | | false | PersistentVolume | +| `pods` | `po` | | true | Pod | +| `podtemplates` | | | true | PodTemplate | +| `replicationcontrollers` | `rc` | | true | ReplicationController | +| `resourcequotas` | `quota` | | true | ResourceQuota | +| `secrets` | | | true | Secret | +| `serviceaccounts` | `sa` | | true | ServiceAccount | +| `services` | `svc` | | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io | false | APIService | +| `controllerrevisions` | | apps | true | ControllerRevision | +| `daemonsets` | `ds` | apps | true | DaemonSet | +| `deployments` | `deploy` | apps | true | Deployment | +| `replicasets` | `rs` | apps | true | ReplicaSet | +| `statefulsets` | `sts` | apps | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch | true | CronJob | +| `jobs` | | batch | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io | true | Lease | +| `endpointslices` | | discovery.k8s.io | true | EndpointSlice | +| `events` | `ev` | events.k8s.io | true | Event | +| `ingresses` | `ing` | extensions | true | Ingress | +| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema | +| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration | +| `ingressclasses` | | networking.k8s.io | false | IngressClass | +| `ingresses` | `ing` | networking.k8s.io | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | +| `runtimeclasses` | | node.k8s.io | false | RuntimeClass | +| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | +| `csidrivers` | | storage.k8s.io | false | CSIDriver | +| `csinodes` | | storage.k8s.io | false | CSINode | +| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | +| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | + +## 출력 옵션 + +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. + +### 출력 서식화 + +모든 `kubectl` 명령의 기본 출력 형식은 사람이 읽을 수 있는 일반 텍스트 형식이다. 특정 형식으로 터미널 창에 세부 정보를 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가할 수 있다. + +#### 구문 + +```shell +kubectl [command] [TYPE] [NAME] -o +``` + +`kubectl` 명령에 따라, 다음과 같은 출력 형식이 지원된다. + +출력 형식 | 설명 +--------------| ----------- +`-o custom-columns=` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다. +`-o custom-columns-file=` | `` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다. +`-o json` | JSON 형식의 API 오브젝트를 출력한다. +`-o jsonpath=