From 0ca23b0e2eefaf195c5c1cf269cbd0a360b2725a Mon Sep 17 00:00:00 2001 From: Sean Date: Mon, 16 May 2022 13:59:29 +0800 Subject: [PATCH 001/202] [fr] Fix `Kubernetes` typo --- content/fr/includes/partner-script.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/fr/includes/partner-script.js b/content/fr/includes/partner-script.js index 8141129a8c..78103493f6 100644 --- a/content/fr/includes/partner-script.js +++ b/content/fr/includes/partner-script.js @@ -509,7 +509,7 @@ name: 'Nirmata', logo: 'nirmata', link: 'https://www.nirmata.com/', - blurb: 'Nirmata - Nirmata Managed Kubernets' + blurb: 'Nirmata - Nirmata Managed Kubernetes' }, { type: 2, From aea153864df64dd4dfa24c2bd54354406c69a72d Mon Sep 17 00:00:00 2001 From: Michael Date: Wed, 29 Jun 2022 07:34:32 +0800 Subject: [PATCH 002/202] [ja] fix link about Katacoda --- content/ja/includes/task-tutorial-prereqs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/includes/task-tutorial-prereqs.md b/content/ja/includes/task-tutorial-prereqs.md index 09e7dda1b2..a17936466c 100644 --- a/content/ja/includes/task-tutorial-prereqs.md +++ b/content/ja/includes/task-tutorial-prereqs.md @@ -3,5 +3,5 @@ Kubernetesクラスターが必要、かつそのクラスターと通信する まだクラスターがない場合、[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)を使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます: -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](http://labs.play-with-k8s.com/) From 05b195b5277724d820eda56ef26f013c570dd77b Mon Sep 17 00:00:00 2001 From: jhvaras Date: Wed, 29 Jun 2022 18:46:16 +0200 Subject: [PATCH 003/202] Replace dead cosigned with sigstore policy-controller `sigstore/cosigned` was moved & renamed to `sigstore/policy-controller`. Previous links are no longer available. --- .../docs/tasks/administer-cluster/verify-signed-images.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/tasks/administer-cluster/verify-signed-images.md b/content/en/docs/tasks/administer-cluster/verify-signed-images.md index 5ae1db1134..61fdd8601d 100644 --- a/content/en/docs/tasks/administer-cluster/verify-signed-images.md +++ b/content/en/docs/tasks/administer-cluster/verify-signed-images.md @@ -64,9 +64,9 @@ section. For non-control plane images ( e.g. [conformance image](https://github.com/kubernetes/kubernetes/blob/master/test/conformance/image/README.md)) , signatures can also be verified at deploy time using -[cosigned](https://docs.sigstore.dev/cosign/kubernetes/#cosigned-admission-controller) -admission controller. To get started with `cosigned` here are a few helpful +[sigstore policy-controller](https://docs.sigstore.dev/policy-controller/overview) +admission controller. To get started with `policy-controller` here are a few helpful resources: -* [Installation](https://github.com/sigstore/helm-charts/tree/main/charts/cosigned) -* [Configuration Options](https://github.com/sigstore/cosign/tree/main/config) +* [Installation](https://github.com/sigstore/helm-charts/tree/main/charts/policy-controller) +* [Configuration Options](https://github.com/sigstore/policy-controller/tree/main/config) From 5dc3e85c8a238c36d20cae7ce904e10d31642c45 Mon Sep 17 00:00:00 2001 From: Jayesh Srivastava Date: Thu, 7 Jul 2022 15:14:51 +0530 Subject: [PATCH 004/202] blog: meet our contributors APAC China region --- ...t-our-contributors-APAC-China-region-03.md | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md diff --git a/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md b/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md new file mode 100644 index 0000000000..f66f445519 --- /dev/null +++ b/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md @@ -0,0 +1,70 @@ +--- + layout: blog + title: "Meet Our Contributors - APAC (China region)" + date: 2022-07-11T12:00:00+0000 + slug: meet-our-contributors-chn-ep-03 + canonicalUrl: https://www.kubernetes.dev/blog/2022/07/11/meet-our-contributors-chn-ep-03/ + --- + + **Authors & Interviewers:** [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Priyanka Saggu](https://github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) + + --- + + Hello, everyone 👋 + + Welcome back to the third episode of the "Meet Our Contributors" blog post series for APAC. + + This post features four outstanding contributors from China, who have played diverse leadership and community roles in the upstream Kubernetes project. + + So, without further ado, let's get straight to the article. + + + ## [Andy Zhang](https://github.com/andyzhangx) + + Andy Zhang currently works for Microsoft China at the Shanghai site. His main focus is on Kubernetes storage drivers. Andy started contributing to Kubernetes about 5 years ago. + + He states that as he is working in Azure Kubernetes Service team and spends most of his time contributing to the Kubernetes community project. Now he is the main contributor of quite a lot Kubernetes subprojects such as Kubernetes cloud provider code. + + His open source contributions are mainly self-motivated. In the last two years he has mentored a few students contributing to Kubernetes through the LFX Mentorship program, some of whom got jobs due to their expertise and contributions on Kubernetes projects. + + Andy is an active member of the China Kubernetes community. He adds that the Kubernetes community has a good guide about how to become members, code reviewers, approvers and finally when he found out that some open source projects are in the very early stage, he actively contributed to those projects and became the project maintainer. + + + ## [Shiming Zhang](https://github.com/wzshiming) + + Shiming Zhang is a Software Engineer working on Kubernetes for DaoCloud in Shanghai, China. + + He has mostly been involved with SIG Node, as a reviewer. His major contributions have mainly been bug fixes and feature improvements in an ongoing [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2712-pod-priority-based-graceful-node-shutdown), all revolving around SIG Node. + + Some of his major PRs are [fixing watchForLockfileContention memory leak](https://github.com/kubernetes/kubernetes/pull/100326), [fixing startupProbe behaviour](https://github.com/kubernetes/kubernetes/pull/101093), [adding Field status.hostIPs for Pod](https://github.com/kubernetes/enhancements/pull/2661). + + + ## [Paco Xu](https://github.com/pacoxu) + + Paco Xu works at DaoCloud, a Shanghai-based cloud-native firm. He works with the infra and the open source team, focusing on enterprise cloud native platforms based on Kubernetes. + + He started with Kubernetes in early 2017 and his first contribution was in March 2018. He started with a bug that he found, but his solution was not that graceful, hence wasn't accepted. He then started with some good first issues, which helped him to a great extent. In addition to this, from 2016 to 2017, he made some minor contributions to Docker. + + Currently, Paco is a reviewer for `kubeadm` (a SIG Cluster Lifecycle product), and for SIG Node. + + Paco says that you should contribute to open source projects you use. For him, an open source project is like a book to learn, getting inspired through discussions with the project maintainers. + + > In my opinion, the best way for me is learning how owners work on the project. + ## [Jintao Zhang](https://github.com/tao12345666333) + + Jintao Zhang is presently employed at API7, where he focuses on ingress and service mesh. + + In 2017, he encountered an issue which led to a community discussion and his contributions to Kubernetes started. Before contributing to Kubernetes, Jintao was a long-time contributor to Docker-related open source projects. + + Currently Jintao is a reviewer for the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) project. + + He suggests keeping track of job opportunities at open source companies so that you can find one that allows you to contribute full time. For new contributors Jintao says that if anyone wants to make a significant contribution to an open source project, then they should choose the project based on their interests and should generously invest time. + + + --- + + + If you have any recommendations/suggestions for who we should interview next, please let us know in the #sig-contribex channel on the Kubernetes Slack. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community. + + + We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋 From 911b8e48695769d06827b4bf9b6669ce1d046616 Mon Sep 17 00:00:00 2001 From: Jayesh Srivastava Date: Thu, 7 Jul 2022 15:32:32 +0530 Subject: [PATCH 005/202] Cleaned up spaces --- ...t-our-contributors-APAC-China-region-03.md | 70 +++++++++---------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md b/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md index f66f445519..9825bcc927 100644 --- a/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md +++ b/content/en/blog/_posts/2022-07-11-meet-our-contributors-APAC-China-region-03.md @@ -1,70 +1,70 @@ --- - layout: blog - title: "Meet Our Contributors - APAC (China region)" - date: 2022-07-11T12:00:00+0000 - slug: meet-our-contributors-chn-ep-03 - canonicalUrl: https://www.kubernetes.dev/blog/2022/07/11/meet-our-contributors-chn-ep-03/ - --- +layout: blog +title: "Meet Our Contributors - APAC (China region)" +date: 2022-07-11T12:00:00+0000 +slug: meet-our-contributors-chn-ep-03 +canonicalUrl: https://www.kubernetes.dev/blog/2022/07/11/meet-our-contributors-chn-ep-03/ +--- - **Authors & Interviewers:** [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Priyanka Saggu](https://github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) +**Authors & Interviewers:** [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Priyanka Saggu](https://github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde) - --- +--- - Hello, everyone 👋 +Hello, everyone 👋 - Welcome back to the third episode of the "Meet Our Contributors" blog post series for APAC. +Welcome back to the third episode of the "Meet Our Contributors" blog post series for APAC. - This post features four outstanding contributors from China, who have played diverse leadership and community roles in the upstream Kubernetes project. +This post features four outstanding contributors from China, who have played diverse leadership and community roles in the upstream Kubernetes project. - So, without further ado, let's get straight to the article. +So, without further ado, let's get straight to the article. - ## [Andy Zhang](https://github.com/andyzhangx) +## [Andy Zhang](https://github.com/andyzhangx) - Andy Zhang currently works for Microsoft China at the Shanghai site. His main focus is on Kubernetes storage drivers. Andy started contributing to Kubernetes about 5 years ago. +Andy Zhang currently works for Microsoft China at the Shanghai site. His main focus is on Kubernetes storage drivers. Andy started contributing to Kubernetes about 5 years ago. - He states that as he is working in Azure Kubernetes Service team and spends most of his time contributing to the Kubernetes community project. Now he is the main contributor of quite a lot Kubernetes subprojects such as Kubernetes cloud provider code. +He states that as he is working in Azure Kubernetes Service team and spends most of his time contributing to the Kubernetes community project. Now he is the main contributor of quite a lot Kubernetes subprojects such as Kubernetes cloud provider code. - His open source contributions are mainly self-motivated. In the last two years he has mentored a few students contributing to Kubernetes through the LFX Mentorship program, some of whom got jobs due to their expertise and contributions on Kubernetes projects. +His open source contributions are mainly self-motivated. In the last two years he has mentored a few students contributing to Kubernetes through the LFX Mentorship program, some of whom got jobs due to their expertise and contributions on Kubernetes projects. - Andy is an active member of the China Kubernetes community. He adds that the Kubernetes community has a good guide about how to become members, code reviewers, approvers and finally when he found out that some open source projects are in the very early stage, he actively contributed to those projects and became the project maintainer. +Andy is an active member of the China Kubernetes community. He adds that the Kubernetes community has a good guide about how to become members, code reviewers, approvers and finally when he found out that some open source projects are in the very early stage, he actively contributed to those projects and became the project maintainer. - ## [Shiming Zhang](https://github.com/wzshiming) +## [Shiming Zhang](https://github.com/wzshiming) - Shiming Zhang is a Software Engineer working on Kubernetes for DaoCloud in Shanghai, China. +Shiming Zhang is a Software Engineer working on Kubernetes for DaoCloud in Shanghai, China. - He has mostly been involved with SIG Node, as a reviewer. His major contributions have mainly been bug fixes and feature improvements in an ongoing [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2712-pod-priority-based-graceful-node-shutdown), all revolving around SIG Node. +He has mostly been involved with SIG Node, as a reviewer. His major contributions have mainly been bug fixes and feature improvements in an ongoing [KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2712-pod-priority-based-graceful-node-shutdown), all revolving around SIG Node. - Some of his major PRs are [fixing watchForLockfileContention memory leak](https://github.com/kubernetes/kubernetes/pull/100326), [fixing startupProbe behaviour](https://github.com/kubernetes/kubernetes/pull/101093), [adding Field status.hostIPs for Pod](https://github.com/kubernetes/enhancements/pull/2661). +Some of his major PRs are [fixing watchForLockfileContention memory leak](https://github.com/kubernetes/kubernetes/pull/100326), [fixing startupProbe behaviour](https://github.com/kubernetes/kubernetes/pull/101093), [adding Field status.hostIPs for Pod](https://github.com/kubernetes/enhancements/pull/2661). - ## [Paco Xu](https://github.com/pacoxu) +## [Paco Xu](https://github.com/pacoxu) - Paco Xu works at DaoCloud, a Shanghai-based cloud-native firm. He works with the infra and the open source team, focusing on enterprise cloud native platforms based on Kubernetes. +Paco Xu works at DaoCloud, a Shanghai-based cloud-native firm. He works with the infra and the open source team, focusing on enterprise cloud native platforms based on Kubernetes. - He started with Kubernetes in early 2017 and his first contribution was in March 2018. He started with a bug that he found, but his solution was not that graceful, hence wasn't accepted. He then started with some good first issues, which helped him to a great extent. In addition to this, from 2016 to 2017, he made some minor contributions to Docker. +He started with Kubernetes in early 2017 and his first contribution was in March 2018. He started with a bug that he found, but his solution was not that graceful, hence wasn't accepted. He then started with some good first issues, which helped him to a great extent. In addition to this, from 2016 to 2017, he made some minor contributions to Docker. - Currently, Paco is a reviewer for `kubeadm` (a SIG Cluster Lifecycle product), and for SIG Node. +Currently, Paco is a reviewer for `kubeadm` (a SIG Cluster Lifecycle product), and for SIG Node. - Paco says that you should contribute to open source projects you use. For him, an open source project is like a book to learn, getting inspired through discussions with the project maintainers. +Paco says that you should contribute to open source projects you use. For him, an open source project is like a book to learn, getting inspired through discussions with the project maintainers. - > In my opinion, the best way for me is learning how owners work on the project. - ## [Jintao Zhang](https://github.com/tao12345666333) +> In my opinion, the best way for me is learning how owners work on the project. +## [Jintao Zhang](https://github.com/tao12345666333) - Jintao Zhang is presently employed at API7, where he focuses on ingress and service mesh. +Jintao Zhang is presently employed at API7, where he focuses on ingress and service mesh. - In 2017, he encountered an issue which led to a community discussion and his contributions to Kubernetes started. Before contributing to Kubernetes, Jintao was a long-time contributor to Docker-related open source projects. +In 2017, he encountered an issue which led to a community discussion and his contributions to Kubernetes started. Before contributing to Kubernetes, Jintao was a long-time contributor to Docker-related open source projects. - Currently Jintao is a reviewer for the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) project. +Currently Jintao is a reviewer for the [ingress-nginx](https://kubernetes.github.io/ingress-nginx/) project. - He suggests keeping track of job opportunities at open source companies so that you can find one that allows you to contribute full time. For new contributors Jintao says that if anyone wants to make a significant contribution to an open source project, then they should choose the project based on their interests and should generously invest time. +He suggests keeping track of job opportunities at open source companies so that you can find one that allows you to contribute full time. For new contributors Jintao says that if anyone wants to make a significant contribution to an open source project, then they should choose the project based on their interests and should generously invest time. - --- +--- - If you have any recommendations/suggestions for who we should interview next, please let us know in the #sig-contribex channel on the Kubernetes Slack. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community. +If you have any recommendations/suggestions for who we should interview next, please let us know in the #sig-contribex channel on the Kubernetes Slack. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community. - We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋 +We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋 From 97902d5e1cf5ddb845ecc46a05abcb4d2d6cc6ff Mon Sep 17 00:00:00 2001 From: Arhell Date: Sun, 10 Jul 2022 13:15:03 +0300 Subject: [PATCH 006/202] [ja] updated soon-to-be-broken link --- content/ja/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 4176d3fe57..7f6b65b8c2 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -746,7 +746,7 @@ spec: * [Creating a Persistent Volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)について学ぶ * [Creating a Persistent Volume Claim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)について学ぶ -* [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md)を読む +* [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md)を読む ### リファレンス From bb7f441b162b692e31118ac113e1d2ca5c5bee98 Mon Sep 17 00:00:00 2001 From: Michael Date: Tue, 12 Jul 2022 22:22:59 +0800 Subject: [PATCH 007/202] [pt-br] resync /partners/_index.html --- content/pt-br/partners/_index.html | 113 ++++++++++------------------- 1 file changed, 37 insertions(+), 76 deletions(-) diff --git a/content/pt-br/partners/_index.html b/content/pt-br/partners/_index.html index a8e90dabfd..88383f3c51 100644 --- a/content/pt-br/partners/_index.html +++ b/content/pt-br/partners/_index.html @@ -7,87 +7,48 @@ cid: parceiros ---
-
-
O Kubernetes trabalha com parceiros para criar uma base de código forte e vibrante que suporte um espectro de plataformas complementares. +
O Kubernetes trabalha com parceiros para criar uma base de código forte e vibrante que suporte um espectro de plataformas complementares.
+
+
+
+
+ Provedores de serviços certificados em Kubernetes
-
-
-
-
- Provedores de serviços certificados em Kubernetes -
-
Provedores de serviços certificados, com profunda experiência em ajudar empresas a adotar Kubernetes com sucesso. -


- -

Interessado em se tornar um KCSP? -
-
-
-
-
- Distribuições certificadas do Kubernetes, plataformas hospedadas e instaladores -
A conformidade com o software garante que a versão de cada fornecedor do Kubernetes suporte as APIs necessárias. -


- -

Interessado em se tornarCertified Kubernetes? -
-
-
-
-
Parceiros de treinamento da Kubernetes -
-
Provedores de treinamento certificados que têm profunda experiência em treinamento em tecnologia nativa em nuvem. -



- -

Interessado em se tornar umKTP? -
-
-
- - - -
- - +
Provedores de serviços certificados, com profunda experiência em ajudar empresas a adotar Kubernetes com sucesso. +


+ +

Interessado em se tornar um + KCSP? +
+
+
+
+
+ Distribuições certificadas do Kubernetes, plataformas hospedadas e instaladores +
A conformidade com o software garante que a versão de cada fornecedor do Kubernetes suporte as APIs necessárias. +


+ +

Interessado em se tornar + Kubernetes Certified? +
+
+
+
+
+ Parceiros de treinamento da Kubernetes +
+
Provedores de treinamento certificados que têm profunda experiência em treinamento em tecnologia nativa em nuvem. +


+ +

Interessado em se tornar um + KTP? +
+
- -
+ {{< cncf-landscape helpers=true >}}
- From b3a32ff5a963f117bf04dbb288428399bc15d74f Mon Sep 17 00:00:00 2001 From: Anubhav Vardhan Date: Fri, 15 Jul 2022 17:11:22 +0530 Subject: [PATCH 008/202] Add Garima Negi as a reviewer --- OWNERS_ALIASES | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 296e743a84..3d7050f1c1 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -86,11 +86,10 @@ aliases: sig-docs-hi-owners: # Admins for Hindi content - anubha-v-ardhan - divya-mohan0209 - - mittalyashu sig-docs-hi-reviews: # PR reviews for Hindi content - anubha-v-ardhan - divya-mohan0209 - - mittalyashu + - Garima-Negi - verma-kunal sig-docs-id-owners: # Admins for Indonesian content - ariscahyadi From 6a322318b6eedfc842a709d80fcc43ab24f3a181 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Tue, 19 Jul 2022 21:56:56 +0900 Subject: [PATCH 009/202] Update outdated files in dev-1.24-ko.2 (R1-R3) --- .../{setup/production-environment => concepts}/windows/_index.md | 0 .../windows/user-guide.md} | 0 .../kubelet-authn-authz.md} | 0 3 files changed, 0 insertions(+), 0 deletions(-) rename content/ko/docs/{setup/production-environment => concepts}/windows/_index.md (100%) rename content/ko/docs/{setup/production-environment/windows/user-guide-windows-containers.md => concepts/windows/user-guide.md} (100%) rename content/ko/docs/reference/{command-line-tools-reference/kubelet-authentication-authorization.md => access-authn-authz/kubelet-authn-authz.md} (100%) diff --git a/content/ko/docs/setup/production-environment/windows/_index.md b/content/ko/docs/concepts/windows/_index.md similarity index 100% rename from content/ko/docs/setup/production-environment/windows/_index.md rename to content/ko/docs/concepts/windows/_index.md diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/concepts/windows/user-guide.md similarity index 100% rename from content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md rename to content/ko/docs/concepts/windows/user-guide.md diff --git a/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/ko/docs/reference/access-authn-authz/kubelet-authn-authz.md similarity index 100% rename from content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md rename to content/ko/docs/reference/access-authn-authz/kubelet-authn-authz.md From 2a9849c7c01af485aed3409881ef2cf2032a20bc Mon Sep 17 00:00:00 2001 From: Wander P da Silva <55059282+wandpsilva@users.noreply.github.com> Date: Wed, 20 Jul 2022 09:27:21 -0300 Subject: [PATCH 010/202] Create Docker.md in portuguese Description of what is docker in portuguese to complement the documentation. --- content/pt-br/docs/reference/glossary/Docker.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/pt-br/docs/reference/glossary/Docker.md diff --git a/content/pt-br/docs/reference/glossary/Docker.md b/content/pt-br/docs/reference/glossary/Docker.md new file mode 100644 index 0000000000..3f10bcee94 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/Docker.md @@ -0,0 +1,17 @@ +--- +title: Docker +id: docker +date: 2018-04-12 +full_link: https://docs.docker.com/engine/ +short_description: > + Docker é uma tecnologia utilizada para prover virtualização a nível do sistema operacional também conhecidoa como containers. + +aka: +tags: +- fundamental +--- +Docker (especificamente, Docker Engine) é um software que provê virtualização a nível do sistema operacional também conhecida como {{< glossary_tooltip text="containers" term_id="container" >}}. + + + +Docker utiliza as funcionalidades de isolamento de recursos do kernel linux como cgroups e kernel namespaces, e a capacidade de unir o sistema de arquivos como OverlayFS e outros para permitir a execução independente de containers dentro de uma única instância linux, sem a necessidade de iniciar a manter maquinas virtuais (VMs). From f04ca62c290795184d56d19e6729c63c9e32da45 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Mon, 11 Jul 2022 13:16:13 +0900 Subject: [PATCH 011/202] [ko] Update outdated files in dev-1.24-ko.2 (M105-M117) --- ...nfigure-java-microservice-interactive.html | 2 +- .../configure-redis-using-configmap.md | 6 ++-- .../create-cluster/cluster-interactive.html | 2 +- .../deploy-app/deploy-interactive.html | 2 +- .../explore/explore-interactive.html | 2 +- .../expose/expose-interactive.html | 2 +- .../scale/scale-interactive.html | 2 +- .../update/update-interactive.html | 2 +- .../tutorials/security/cluster-level-pss.md | 11 ++++--- .../ko/docs/tutorials/services/source-ip.md | 33 +++---------------- .../mysql-wordpress-persistent-volume.md | 2 +- .../stateful-application/zookeeper.md | 4 +-- 12 files changed, 25 insertions(+), 45 deletions(-) diff --git a/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html index 3f61c6fa52..414d1b3097 100644 --- a/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html +++ b/content/ko/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index fb1ac922fc..d898ac591e 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -8,7 +8,7 @@ content_type: tutorial -이 페이지에서는 컨피그맵(ConfigMap)을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다. +이 페이지에서는 컨피그맵(ConfigMap)을 사용해서 Redis를 설정하는 방법에 대한 실세계 예제를 제공하고, [컨피그맵을 사용해서 파드 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/) 태스크로 빌드를 한다. @@ -27,7 +27,7 @@ content_type: tutorial {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * 예시는 `kubectl` 1.14 이상 버전에서 동작한다. -* [컨피그맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다. +* [컨피그맵을 사용해서 파드 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다. @@ -78,7 +78,7 @@ kubectl get pod/redis configmap/example-redis-config 다음의 결과를 볼 수 있다. -```shell +``` NAME READY STATUS RESTARTS AGE pod/redis 1/1 Running 0 8s diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 7c66225037..b635f4f6f2 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index d5aca028e7..c67f9ad124 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index d467fc9b2c..6e710c8099 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index fa68a4c40e..cf6abdccd9 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 18a371fff2..ace5f93f17 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html index 0f25073ca3..b644355c4e 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/ko/docs/tutorials/security/cluster-level-pss.md b/content/ko/docs/tutorials/security/cluster-level-pss.md index baa0a6ec05..3d576afc38 100644 --- a/content/ko/docs/tutorials/security/cluster-level-pss.md +++ b/content/ko/docs/tutorials/security/cluster-level-pss.md @@ -19,6 +19,9 @@ weight: 10 파드 시큐리티 스탠다드를 특정 네임스페이스에 적용하려면, [파드 시큐리티 스탠다드를 네임스페이스 수준에 적용하기](/ko/docs/tutorials/security/ns-level-pss/)를 참고한다. +만약 쿠버네티스 버전이 v{{< skew currentVersion >}}이 아니라면, +해당 버전의 문서를 확인하자. + ## {{% heading "prerequisites" %}} 워크스테이션에 다음을 설치한다. @@ -38,12 +41,12 @@ weight: 10 1. 파드 시큐리티 스탠다드가 적용되지 않은 클러스터를 생성한다. ```shell - kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 + kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.24.0 ``` 다음과 비슷하게 출력될 것이다. ``` Creating cluster "psa-wo-cluster-pss" ... - ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ @@ -245,12 +248,12 @@ weight: 10 파드 시큐리티 어드미션을 사용하는 클러스터를 생성한다. ```shell - kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml + kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml ``` 다음과 비슷하게 출력될 것이다. ``` Creating cluster "psa-with-cluster-pss" ... - ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 56489347d6..79ca5dca84 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -204,21 +204,9 @@ client_address=10.240.0.3 * 파드의 응답은 node2로 다시 라우팅된다. * 파드의 응답은 클라이언트로 다시 전송된다. -시각적으로 +이를 그림으로 표현하면 다음과 같다. -{{< mermaid >}} -graph LR; - client(client)-->node2[Node 2]; - node2-->client; - node2-. SNAT .->node1[Node 1]; - node1-. SNAT .->node2; - node1-->endpoint(Endpoint); - - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - class node1,node2,endpoint k8s; - class client plain; -{{}} +{{< figure src="/docs/images/tutor-service-nodePort-fig01.svg" alt="source IP nodeport figure 01" class="diagram-large" caption="그림. Source IP Type=NodePort using SNAT" link="https://mermaid.live/edit#pako:eNqNkV9rwyAUxb-K3LysYEqS_WFYKAzat9GHdW9zDxKvi9RoMIZtlH732ZjSbE970cu5v3s86hFqJxEYfHjRNeT5ZcUtIbXRaMNN2hZ5vrYRqt52cSXV-4iMSuwkZiYtyX739EqWaahMQ-V1qPxDVLNOvkYrO6fj2dupWMR2iiT6foOKdEZoS5Q2hmVSStoH7w7IMqXUVOefWoaG3XVftHbGeZYVRbH6ZXJ47CeL2-qhxvt_ucTe1SUlpuMN6CX12XeGpLdJiaMMFFr0rdAyvvfxjHEIDbbIgcVSohKDCRy4PUV06KQIuJU6OA9MCdMjBTEEt_-2NbDgB7xAGy3i97VJPP0ABRmcqg" >}} 이를 피하기 위해 쿠버네티스는 [클라이언트 소스 IP 주소를 보존](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다. @@ -260,20 +248,9 @@ client_address=104.132.1.79 * 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다. * node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다. -시각적으로 +이를 시각적으로 표현하면 다음과 같다. -{{< mermaid >}} -graph TD; - client --> node1[Node 1]; - client(client) --x node2[Node 2]; - node1 --> endpoint(endpoint); - endpoint --> node1; - - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - class node1,node2,endpoint k8s; - class client plain; -{{}} +{{< figure src="/docs/images/tutor-service-nodePort-fig02.svg" alt="source IP nodeport figure 02" class="diagram-large" caption="그림. Source IP Type=NodePort preserves client source IP address" link="" >}} @@ -324,7 +301,7 @@ client_address=10.240.0.5 강제로 로드밸런싱 트래픽을 받을 수 있는 노드 목록에서 자신을 스스로 제거한다. -시각적으로: +이를 그림으로 표현하면 다음과 같다. ![Source IP with externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index b8887d9358..3b75ce0b34 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -16,7 +16,7 @@ card: [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/ko/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다. {{< warning >}} -이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자. +이 배포는 프로덕션 사용 예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress)로 배포하기를 고려해보자. {{< /warning >}} {{< note >}} diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index b9cf603032..7eec05728f 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -122,7 +122,7 @@ zk-2 1/1 Running 0 40s ``` 스테이트풀셋 컨트롤러는 3개의 파드를 생성하고, 각 파드는 -[ZooKeeper](https://www-us.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다. +[ZooKeeper](https://archive.apache.org/dist/zookeeper/stable/) 서버를 포함한 컨테이너를 가진다. ### 리더 선출 촉진 @@ -305,7 +305,7 @@ numChildren = 0 ### 내구성있는 저장소 제공 -[ZooKeeper 기본](#zookeeper-basics) 섹션에서 언급했듯이 +[ZooKeeper 기본](#zookeeper) 섹션에서 언급했듯이 ZooKeeper는 모든 항목을 내구성있는 WAL에 커밋하고 메모리 상태의 스냅샷을 저장 미디에에 주기적으로 저장한다. 내구성을 제공하기 위해 WAL을 이용하는 것은 복제된 상태 머신을 이루는 합의 프로토콜에서 From 249a9e02337f5714969901841a344eb8f8f8b445 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Tue, 19 Jul 2022 21:23:56 +0900 Subject: [PATCH 012/202] Update outdated files in dev-1.24-ko.2 (M101-M104) --- content/ko/docs/tasks/tls/certificate-rotation.md | 2 +- .../tools/included/optional-kubectl-configs-bash-linux.md | 2 +- .../tasks/tools/included/optional-kubectl-configs-bash-mac.md | 2 +- content/ko/docs/tasks/tools/install-kubectl-linux.md | 3 +-- 4 files changed, 4 insertions(+), 5 deletions(-) diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md index eadec87b4f..5f980de2e4 100644 --- a/content/ko/docs/tasks/tls/certificate-rotation.md +++ b/content/ko/docs/tasks/tls/certificate-rotation.md @@ -28,7 +28,7 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다. 너무 자주 갱신할 필요는 없다. 쿠버네티스는 [kubelet 인증서 -갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며, +갱신](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 포함하며, 이 기능은 현재 인증서의 만료 시한이 임박한 경우, 새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 기능이다. 새로운 인증서를 사용할 수 있게 되면 diff --git a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md index e7ce12f559..cf1096aeb6 100644 --- a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md +++ b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md @@ -43,7 +43,7 @@ kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 ```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/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md index 7acb5d3621..a9a66a63c8 100644 --- a/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md +++ b/content/ko/docs/tasks/tools/included/optional-kubectl-configs-bash-mac.md @@ -77,7 +77,7 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d" ```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 ``` - Homebrew로 kubectl을 설치한 경우([여기](/ko/docs/tasks/tools/install-kubectl-macos/#install-with-homebrew-on-macos)의 설명을 참고), kubectl 자동 완성 스크립트가 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있을 것이다. 이 경우, 아무 것도 할 필요가 없다. diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index df5165c090..bb7605fde4 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -138,10 +138,9 @@ card: cat < Date: Mon, 18 Jul 2022 04:41:44 -0700 Subject: [PATCH 013/202] Translate tasks/extend-kubernetes/configure-multiple-schedulers to Korean Reflected bconfiden2's comments and deleted unnecessary blank spaces between links Reflected seokho-son's comments Reflected seokho-sons' comments (fixed missed errors) --- .../configure-multiple-schedulers.md | 219 ++++++++++++++++++ .../ko/examples/admin/sched/clusterrole.yaml | 37 +++ .../ko/examples/admin/sched/my-scheduler.yaml | 99 ++++++++ content/ko/examples/admin/sched/pod1.yaml | 10 + content/ko/examples/admin/sched/pod2.yaml | 11 + content/ko/examples/admin/sched/pod3.yaml | 11 + 6 files changed, 387 insertions(+) create mode 100644 content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md create mode 100644 content/ko/examples/admin/sched/clusterrole.yaml create mode 100644 content/ko/examples/admin/sched/my-scheduler.yaml create mode 100644 content/ko/examples/admin/sched/pod1.yaml create mode 100644 content/ko/examples/admin/sched/pod2.yaml create mode 100644 content/ko/examples/admin/sched/pod3.yaml diff --git a/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md new file mode 100644 index 0000000000..19ef92ec33 --- /dev/null +++ b/content/ko/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -0,0 +1,219 @@ +--- +reviewers: + + +title: 다중 스케줄러 설정 +content_type: task +weight: 20 +--- + + + +쿠버네티스는 [여기](/docs/reference/command-line-tools-reference/kube-scheduler/)에서 +설명한 스케줄러를 기본 스케줄러로 사용한다. +만일 기본 스케줄러가 사용자의 필요를 만족시키지 못한다면 직접 스케줄러를 구현하여 사용할 수 있다. +이에 더해, 기본 스케줄러와 함께 여러 스케줄러를 동시에 사용하여 +쿠버네티스가 각 파드에 대해 어떤 스케줄러를 적용할지에 대한 설정도 할 수 있다. +예제와 함께 쿠버네티스에서 다중 스케줄러를 사용하는 방법에 대해 배워보도록 하자. + +스케줄러를 구현하는 방법에 대한 자세한 설명은 해당 문서에서 다루지 않는다. +kube-scheduler 구현을 다루는 공식 예시는 쿠버네티스 소스 디렉토리에 있는 +[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler) +를 참고한다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## 스케줄러 패키징 + +스케줄러 바이너리를 컨테이너 이미지로 패키징한다. 해당 예제를 통해 +기본 스케줄러 (kube-scheduler)를 두 번째 스케줄러로 사용할 수 있다. +[GitHub 쿠버네티스 소스코드](https://github.com/kubernetes/kubernetes)를 +클론하고 소스를 빌드하자. + +```shell +git clone https://github.com/kubernetes/kubernetes.git +cd kubernetes +make +``` + +kube-scheduler 바이너리를 담은 컨테이너 이미지를 생성하자. +이미지를 빌드 하기 위한 `Dockerfile`은 다음과 같다. + +```docker +FROM busybox +ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler +``` + +파일을 `Dockerfile`로 저장하고 이미지를 빌드한 후 레지스트리로 푸시하자. 해당 예제에서는 이미지를 +[Google Container Registry (GCR)](https://cloud.google.com/container-registry/)로 +푸시하고 있다. +이에 대한 자세한 내용은 GCR +[문서](https://cloud.google.com/container-registry/docs/)를 참고하자. + +```shell +docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 . +gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0 +``` + +## 스케줄러에서 사용할 쿠버네티스 디플로이먼트 정의하기 + +이제 스케줄러 컨테이너 이미지가 있으니, 해당 이미지를 포함하는 파드 구성을 생성하고 +쿠버네티스 클러스터 내에서 실행해보자. 해당 예제에서는, 클러스터 내에 직접 파드를 생성하는 대신에 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용해도 된다. +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)는 +[레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)을 관리하며, +이는 또 파드를 관리하기 때문에 스케줄러에 대한 회복 탄력성을 제공한다. +다음은 디플로이먼트에 대한 구성 파일이다. 이 파일을 `my-scheduler.yaml`으로 저장한다. + +{{< codenew file="admin/sched/my-scheduler.yaml" >}} + +해당 매니페스트에서는 [KubeSchedulerConfiguration](/ko/docs/reference/scheduling/config/)을 +사용하여 구현할 스케줄러의 특성을 정의한다. 이러한 설정은 초기화 과정에서 `--config` 옵션을 통해 `kube-scheduler`에게 전달된다. +해당 구성 파일은 `my-scheduler-config` 컨피그맵에 저장된다. `my-scheduler` 디플로이먼트의 파드에서는 `my-scheduler-config` 컨피그맵을 볼륨으로 마운트 시킨다. + +앞서 언급한 스케줄러 구성에서는, 구현한 스케줄러가 +[KubeSchedulerProfile](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-KubeSchedulerProfile)의 형식으로 나타나게 된다. +{{< note >}} +스케줄러가 특정 파드에 대한 스케줄링을 수행하는지 판단하기 위해서는, PodTemplate 또는 파드 매니페스트의 +`spec.schedulerName` 필드가 `KubeSchedulerProfile`의 `schedulerName` 필드와 일치하는지 확인해야 한다. +클러스터 내 실행되고 있는 모든 스케줄러는 고유한 이름을 가져야 한다. +{{< /note >}} + +또한, `kube-scheduler`와 같은 권한을 부여받기 위해서는 전용 서비스 어카운트 `my-scheduler`를 생성하고 +해당 서비스 어카운트를 클러스터롤 `system:kube-scheduler`와 바인딩해야 한다. + +이외의 커맨드 라인 인자에 대한 자세한 설명은 +[kube-scheduler 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)에서 참고하고 +이외의 사용자 정의 `kube-scheduler` 구성에 대한 자세한 설명은 +[스케줄러 구성 레퍼런스](/docs/reference/config-api/kube-scheduler-config.v1beta3/) +에서 참고한다. + +## 두 번째 스케줄러를 클러스터에서 실행하기 + +쿠버네티스 클러스터에서 스케줄러를 실행하기 위해서, +위의 구성 파일에서 명시한 디플로이먼트를 쿠버네티스 클러스터 내에 생성한다. + +```shell +kubectl create -f my-scheduler.yaml +``` + +스케줄러 파드가 실행되고 있는지 확인한다. + +```shell +kubectl get pods --namespace=kube-system +``` + +``` +NAME READY STATUS RESTARTS AGE +.... +my-scheduler-lnf4s-4744f 1/1 Running 0 2m +... +``` + +기본 kube-scheduler 파드와 더불어, +my-scheduler 파드가 실행("Running")되고 있다는 것을 목록에서 볼 수 있을 것이다. + +### 리더 선출 활성화 + +리더 선출이 활성화된 상태로 다중 스케줄러를 실행하기 위해서는 다음과 같은 작업을 수행해야 한다. + +`my-scheduler-config` 컨피그맵의 YAML 파일에서 KubeSchedulerConfiguration의 다음과 같은 필드들을 갱신한다. + +* `leaderElection.leaderElect` 를 `true` 로 +* `leaderElection.resourceNamespace` 를 `` 로 +* `leaderElection.resourceName` 을 `` 으로 + +{{< note >}} +컨트롤 플레인이 잠금 오브젝트를 생성해 주지만, 해당 네임스페이스가 존재하는 상태이어야 한다. +`kube-system` 네임스페이스를 사용해도 된다. +{{< /note >}} + +클러스터 내에 RBAC가 활성화되어 있는 상태라면, `system:kube-scheduler` 클러스터롤을 업데이트 해야 한다. +다음 예시와 같이, 구현한 스케줄러의 이름을 `endpoints`와 `leases` 리소스에 적용되는 룰의 resourceNames에 추가하자. + +```shell +kubectl edit clusterrole system:kube-scheduler +``` + +{{< codenew file="admin/sched/clusterrole.yaml" >}} + +## 파드의 스케줄러를 지정하기 + +이제 두 번째 스케줄러가 실행되고 있으니, +파드를 몇 개 생성하여 기본 스케줄러 또는 새로 배치한 스케줄러에 의해 스케줄링이 되도록 설정해 보자. +특정 스케줄러를 이용하여 파드를 스케줄링하기 위해서는 +해당 파드의 명세에 해당 스케줄러의 이름을 명시해야 한다. 세 가지 예시를 참고해 보자. + +- 스케줄러 이름을 명시하지 않은 파드 명세 + + {{< codenew file="admin/sched/pod1.yaml" >}} + + 스케줄러 이름을 제공받지 못했다면, + 파드는 자동으로 기본 스케줄러에 의해 스케줄링이 수행된다. + + 해당 파일을 `pod1.yaml`로 저장하고 쿠버네티스 클러스터에 제출해 보자. + + ```shell + kubectl create -f pod1.yaml + ``` + +- `default-scheduler`를 명시한 파드 명세 + + {{< codenew file="admin/sched/pod2.yaml" >}} + + `spec.schedulerName`의 값으로 스케줄러 이름을 제공함으로써 스케줄러가 정해진다. + 이와 같은 경우에서는, 기본 스케줄러의 이름인 `default-scheduler`를 명시하고 있다. + + 해당 파일을 `pod2.yaml`로 저장하고 쿠버네티스 클러스터에 제출해 보자. + + ```shell + kubectl create -f pod2.yaml + ``` + +- `my-scheduler`를 명시한 파드 명세 + + {{< codenew file="admin/sched/pod3.yaml" >}} + + 이와 같은 경우에서는, 직접 배치한 스케줄러 - `my-scheduler`를 통해 + 해당 파드의 스케줄링이 수행되어야 한다는 것을 명시하고 있다. + `spec.schedulerName`의 값은 `KubeSchedulerProfile` 매핑의 `schedulerName` 필드와 일치해야 한다. + + 해당 파일을 `pod3.yaml`로 저장하고 쿠버네티스 클러스터에 제출해 보자. + + ```shell + kubectl create -f pod3.yaml + ``` + + 세 개의 파드가 모두 실행되고 있는지 확인해 보자. + + ```shell + kubectl get pods + ``` + + + +### 파드가 원하는 스케줄러에 의해 스케줄링 되었는지 확인해보기 + +이번 예제들을 수월하게 진행하기 위해, +파드가 실제로 원하는 스케줄러에 의해 스케줄링되고 있는지 확인해 보지 않았다. +해당 사항은 파드와 디플로이먼트 구성 파일의 제출 순서를 바꿔보면 확인해 볼 수 있다. +만일 스케줄러 디플로이먼트 구성 파일을 제출하기 전에 모든 파드의 구성 파일을 쿠버네티스 클러스터에 제출한다면, +다른 두 개의 파드는 스케줄링 되는 와중에 `annotation-second-scheduler` 파드는 +무기한 "Pending" 상태에 머무르는 것을 관찰할 수 있다. +스케줄러 디플로이먼트 구성 파일을 제출하여 새로운 스케줄러가 실행되기 시작하면, +`annotation-second-scheduler` 파드도 스케줄링 된다. + +다른 방법으로는, 이벤트 로그에서 "Scheduled" 항목을 찾아 +파드가 원하는 스케줄러에 의해 스케줄링 되었는지 확인해 볼 수 있다. + +```shell +kubectl get events +``` +또한, 관련된 컨트롤 플레인 노드들의 스태틱 파드 매니페스트를 수정하면 클러스터의 메인 스케줄러로 +[사용자 정의 스케줄러 구성](/ko/docs/reference/scheduling/config/#multiple-profiles) +또는 사용자 정의 컨테이너 이미지를 사용할 수도 있다. + diff --git a/content/ko/examples/admin/sched/clusterrole.yaml b/content/ko/examples/admin/sched/clusterrole.yaml new file mode 100644 index 0000000000..554b8659db --- /dev/null +++ b/content/ko/examples/admin/sched/clusterrole.yaml @@ -0,0 +1,37 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler +rules: + - apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: + - create + - apiGroups: + - coordination.k8s.io + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - leases + verbs: + - get + - update + - apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update diff --git a/content/ko/examples/admin/sched/my-scheduler.yaml b/content/ko/examples/admin/sched/my-scheduler.yaml new file mode 100644 index 0000000000..5addf9e0e6 --- /dev/null +++ b/content/ko/examples/admin/sched/my-scheduler.yaml @@ -0,0 +1,99 @@ +apiVersion: v1 +kind: ServiceAccount +metadata: + name: my-scheduler + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-kube-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-volume-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:volume-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: v1 +kind: ConfigMap +metadata: + name: my-scheduler-config + namespace: kube-system +data: + my-scheduler-config.yaml: | + apiVersion: kubescheduler.config.k8s.io/v1beta2 + kind: KubeSchedulerConfiguration + profiles: + - schedulerName: my-scheduler + leaderElection: + leaderElect: false +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + component: scheduler + tier: control-plane + name: my-scheduler + namespace: kube-system +spec: + selector: + matchLabels: + component: scheduler + tier: control-plane + replicas: 1 + template: + metadata: + labels: + component: scheduler + tier: control-plane + version: second + spec: + serviceAccountName: my-scheduler + containers: + - command: + - /usr/local/bin/kube-scheduler + - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml + image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 + livenessProbe: + httpGet: + path: /healthz + port: 10259 + scheme: HTTPS + initialDelaySeconds: 15 + name: kube-second-scheduler + readinessProbe: + httpGet: + path: /healthz + port: 10259 + scheme: HTTPS + resources: + requests: + cpu: '0.1' + securityContext: + privileged: false + volumeMounts: + - name: config-volume + mountPath: /etc/kubernetes/my-scheduler + hostNetwork: false + hostPID: false + volumes: + - name: config-volume + configMap: + name: my-scheduler-config diff --git a/content/ko/examples/admin/sched/pod1.yaml b/content/ko/examples/admin/sched/pod1.yaml new file mode 100644 index 0000000000..560b6aa0fb --- /dev/null +++ b/content/ko/examples/admin/sched/pod1.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: no-annotation + labels: + name: multischeduler-example +spec: + containers: + - name: pod-with-no-annotation-container + image: k8s.gcr.io/pause:2.0 \ No newline at end of file diff --git a/content/ko/examples/admin/sched/pod2.yaml b/content/ko/examples/admin/sched/pod2.yaml new file mode 100644 index 0000000000..2f065efe65 --- /dev/null +++ b/content/ko/examples/admin/sched/pod2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-default-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: default-scheduler + containers: + - name: pod-with-default-annotation-container + image: k8s.gcr.io/pause:2.0 diff --git a/content/ko/examples/admin/sched/pod3.yaml b/content/ko/examples/admin/sched/pod3.yaml new file mode 100644 index 0000000000..a1b8db3200 --- /dev/null +++ b/content/ko/examples/admin/sched/pod3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-second-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: my-scheduler + containers: + - name: pod-with-second-annotation-container + image: k8s.gcr.io/pause:2.0 From 469c4b426abea80b654a6b8fb36201c932f12fff Mon Sep 17 00:00:00 2001 From: Nitish Kumar Date: Fri, 22 Jul 2022 20:36:32 +0530 Subject: [PATCH 014/202] Minor typo in korean docs fixed: Fix 02 --- content/ko/docs/reference/access-authn-authz/authorization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index 3c9c4e2280..18da992eb1 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -96,7 +96,7 @@ DELETE | delete(개별 리소스), deletecollection(리소스 모음) #### API 접근 확인 -`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다. +`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 `auth can-i` 하위 명령어를 제공한다. 이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며, 사용되는 인가 모드에 관계없이 작동한다. From 61aa30b74be065a0e28ce67f5ac1bd9026227f6d Mon Sep 17 00:00:00 2001 From: shine09 Date: Mon, 25 Jul 2022 13:50:19 +0900 Subject: [PATCH 015/202] Update outdated content on M118-M125 + Pre-apply source updates on 34359 and one more --- content/ko/examples/application/mysql/mysql-configmap.yaml | 7 +++---- content/ko/examples/application/mysql/mysql-services.yaml | 3 +++ .../ko/examples/application/mysql/mysql-statefulset.yaml | 2 ++ content/ko/examples/controllers/job.yaml | 2 +- .../ko/examples/pods/pod-with-affinity-anti-affinity.yaml | 2 +- content/ko/includes/task-tutorial-prereqs.md | 4 ++-- content/ko/releases/_index.md | 2 +- content/ko/releases/version-skew-policy.md | 4 ++-- 8 files changed, 15 insertions(+), 11 deletions(-) diff --git a/content/ko/examples/application/mysql/mysql-configmap.yaml b/content/ko/examples/application/mysql/mysql-configmap.yaml index 538f9f3324..5f13dfd7a3 100644 --- a/content/ko/examples/application/mysql/mysql-configmap.yaml +++ b/content/ko/examples/application/mysql/mysql-configmap.yaml @@ -4,15 +4,14 @@ metadata: name: mysql labels: app: mysql + app.kubernetes.io/name: mysql data: primary.cnf: | # Primary에만 이 구성을 적용한다. [mysqld] - log-bin - datadir=/var/lib/mysql/mysql + log-bin replica.cnf: | # 레플리카에만 이 구성을 적용한다. [mysqld] - super-read-only - datadir=/var/lib/mysql/mysql + super-read-only diff --git a/content/ko/examples/application/mysql/mysql-services.yaml b/content/ko/examples/application/mysql/mysql-services.yaml index c5cfa4936b..f753b28457 100644 --- a/content/ko/examples/application/mysql/mysql-services.yaml +++ b/content/ko/examples/application/mysql/mysql-services.yaml @@ -5,6 +5,7 @@ metadata: name: mysql labels: app: mysql + app.kubernetes.io/name: mysql spec: ports: - name: mysql @@ -21,6 +22,8 @@ metadata: name: mysql-read labels: app: mysql + app.kubernetes.io/name: mysql + readonly: "true" spec: ports: - name: mysql diff --git a/content/ko/examples/application/mysql/mysql-statefulset.yaml b/content/ko/examples/application/mysql/mysql-statefulset.yaml index 5c6259a66d..8bed6ee51d 100644 --- a/content/ko/examples/application/mysql/mysql-statefulset.yaml +++ b/content/ko/examples/application/mysql/mysql-statefulset.yaml @@ -6,12 +6,14 @@ spec: selector: matchLabels: app: mysql + app.kubernetes.io/name: mysql serviceName: mysql replicas: 3 template: metadata: labels: app: mysql + app.kubernetes.io/name: mysql spec: initContainers: - name: init-mysql diff --git a/content/ko/examples/controllers/job.yaml b/content/ko/examples/controllers/job.yaml index b448f2eb81..d8befe89db 100644 --- a/content/ko/examples/controllers/job.yaml +++ b/content/ko/examples/controllers/job.yaml @@ -7,7 +7,7 @@ spec: spec: containers: - name: pi - image: perl + image: perl:5.34.0 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never backoffLimit: 4 diff --git a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml index 5dcc7693b6..e1aae9498c 100644 --- a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -30,4 +30,4 @@ spec: - key-2 containers: - name: with-node-affinity - image: k8s.gcr.io/pause:2.0 + image: k8s.gcr.io/pause:2.0 diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md index 9109e34433..fc87f61bfd 100644 --- a/content/ko/includes/task-tutorial-prereqs.md +++ b/content/ko/includes/task-tutorial-prereqs.md @@ -2,7 +2,7 @@ 통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 있지 않다면, [minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나 -다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. +다음 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. -* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](https://labs.play-with-k8s.com/) diff --git a/content/ko/releases/_index.md b/content/ko/releases/_index.md index 0bc57340a3..284f004622 100644 --- a/content/ko/releases/_index.md +++ b/content/ko/releases/_index.md @@ -12,7 +12,7 @@ type: docs 쿠버네티스 버전은 **x.y.z** 의 형태로 표현되는데, **x** 는 메이저(major) 버전, **y** 는 마이너(minor), **z** 는 패치(patch) 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/)의 용어를 따른 것이다. -저 자세한 정보는 [버전 차이(skew) 정책](/releases/version-skew-policy/) 문서에서 확인하길 바란다. +자세한 정보는 [버전 차이(skew) 정책](/releases/version-skew-policy/) 문서에서 확인하길 바란다. diff --git a/content/ko/releases/version-skew-policy.md b/content/ko/releases/version-skew-policy.md index ef68b0b341..9fd14376d2 100644 --- a/content/ko/releases/version-skew-policy.md +++ b/content/ko/releases/version-skew-policy.md @@ -21,12 +21,12 @@ description: > ## 지원되는 버전 쿠버네티스 버전은 **x.y.z** 로 표현되는데, 여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다. -자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다. +자세한 내용은 [쿠버네티스 릴리스 버전](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning)을 참조한다. 쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다. 보안 수정사항을 포함한 해당 수정사항은 심각도와 타당성에 따라 세 개의 릴리스 브랜치로 백포트(backport) 될 수 있다. -패치 릴리스는 각 브랜치별로 [정기적인 주기](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다. +패치 릴리스는 각 브랜치별로 [정기적인 주기](/releases/patch-releases/#cadence)로 제공하며, 필요한 경우 추가 긴급 릴리스도 추가한다. [릴리스 관리자](/releases/release-managers/) 그룹이 이러한 결정 권한을 가진다. From 9cde087b60e87c6fd9649bcb508e080c20584af1 Mon Sep 17 00:00:00 2001 From: Jinny Park Date: Mon, 25 Jul 2022 20:28:58 +0900 Subject: [PATCH 016/202] [ko]Translate the glossary term Add-ons into Korean --- content/ko/docs/reference/glossary/addons.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 content/ko/docs/reference/glossary/addons.md diff --git a/content/ko/docs/reference/glossary/addons.md b/content/ko/docs/reference/glossary/addons.md new file mode 100644 index 0000000000..5c3a034d0a --- /dev/null +++ b/content/ko/docs/reference/glossary/addons.md @@ -0,0 +1,16 @@ +--- +title: 애드온(Add-ons) +id: addons +date: 2019-12-15 +full_link: /ko/docs/concepts/cluster-administration/addons/ +short_description: > + 쿠버네티스의 기능을 확장하는 리소스. + +aka: +tags: +- tool +--- + 쿠버네티스의 기능을 확장하는 리소스. + + +[애드온 설치](/ko/docs/concepts/cluster-administration/addons/)에서는 클러스터에서 애드온을 사용하는 자세한 방법을 설명하며, 인기 있는 애드온들을 나열한다. From dc91547cbf4c6caf5987bd52f0f20c5cc7d9a3ab Mon Sep 17 00:00:00 2001 From: KimDoubleB Date: Mon, 25 Jul 2022 20:39:48 +0900 Subject: [PATCH 017/202] [ko] Update outdated files dev-1.24-ko.2 (M80-M83) --- .../manage-resources/cpu-constraint-namespace.md | 11 +++++++---- .../manage-resources/cpu-default-namespace.md | 3 ++- .../manage-resources/memory-constraint-namespace.md | 7 ++++--- .../manage-resources/memory-default-namespace.md | 2 +- 4 files changed, 14 insertions(+), 9 deletions(-) diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 9ec6eb119a..9a48a1da05 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -27,7 +27,7 @@ CPU의 최솟값과 최댓값을 지정한다. 클러스터에 네임스페이스를 생성할 수 있는 권한이 있어야 한다. -태스크 예제를 실행하려면 클러스터에 적어도 1.0 CPU 이상이 사용 가능해야 한다. +클러스터의 각 노드는 파드 실행을 위해 적어도 1.0 CPU 이상이 사용 가능해야 한다. 쿠버네티스에서 “1 CPU”가 무엇을 의미하는지 알아보려면 [CPU의 의미](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)를 참조한다. @@ -45,7 +45,7 @@ kubectl create namespace constraints-cpu-example ## 리밋레인지와 파드 생성 -다음은 리밋레인지에 대한 예시 매니페스트이다. +다음은 {{< glossary_tooltip text="리밋레인지" term_id="limitrange" >}} 예제 매니페스트이다. {{< codenew file="admin/resource/cpu-constraints.yaml" >}} @@ -95,7 +95,7 @@ limits: {{< /note >}} 다음은 컨테이너가 하나인 파드의 매니페스트이다. 컨테이너 매니페스트는 -500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 리밋레인지에 +500 millicpu의 CPU 요청량 및 800 millicpu의 CPU 상한을 지정하고 있다. 이는 이 네임스페이스의 리밋레인지에 의해 부과된 CPU의 최소와 최대 제약 조건을 충족시킨다. {{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}} @@ -214,7 +214,10 @@ resources: [CPU 요청량과 상한의 기본값](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)을 적용했다. -이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 클러스터에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, 노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. 2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다. +이 시점에서, 파드는 실행 중일 수도 있고 아닐 수도 있다. 이 태스크의 전제 조건은 +노드에 1 CPU 이상 사용 가능해야 한다는 것이다. 각 노드에 1 CPU만 있는 경우, +노드에 할당할 수 있는 CPU가 800 millicpu의 요청량을 수용하기에 충분하지 않을 수 있다. +2 CPU인 노드를 사용하는 경우에는, CPU가 800 millicpu 요청량을 수용하기에 충분할 것이다. 파드를 삭제한다. diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md index f7c09e159d..1a066c6a86 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace.md @@ -140,7 +140,8 @@ resources: kubectl apply -f https://k8s.io/examples/admin/resource/cpu-defaults-pod-3.yaml --namespace=default-cpu-example ``` -생성한 파드의 명세를 확인한다. +생성한 파드의 +[명세](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status)를 확인한다. ``` kubectl get pod default-cpu-demo-3 --output=yaml --namespace=default-cpu-example diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index ef6c5b5580..50f67d8bc0 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -10,8 +10,9 @@ description: >- -이 페이지는 네임스페이스에서 실행되는 컨테이너가 사용하는 메모리의 최솟값과 최댓값을 -설정하는 방법을 보여준다. [리밋레인지(LimitRange)](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}에서 +실행되는 컨테이너가 사용하는 메모리의 최솟값과 최댓값을 설정하는 방법을 보여준다. +[리밋레인지(LimitRange)](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) 오브젝트에 최소 및 최대 메모리 값을 지정한다. 파드가 리밋레인지에 의해 부과된 제약 조건을 충족하지 않으면, 네임스페이스에서 생성될 수 없다. @@ -77,7 +78,7 @@ kubectl get limitrange mem-min-max-demo-lr --namespace=constraints-mem-example - 쿠버네티스는 다음 단계를 수행한다. * 해당 파드의 어떤 컨테이너도 자체 메모리 요청량(request)과 상한(limit)을 명시하지 않으면, - 해당 컨테이너에 메모리 요청량과 상한의 기본값(default)을 지정한다. +컨트롤 플레인이 해당 컨테이너에 메모리 요청량과 상한의 기본값(default)을 지정한다. * 해당 파드의 모든 컨테이너의 메모리 요청량이 최소 500 MiB 이상인지 확인한다. diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index 3f97d9b6f4..ad6885313e 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -172,7 +172,7 @@ resources: 네임스페이스에 {{< glossary_tooltip text="리소스 쿼터" term_id="resource-quota" >}}가 설정되어 있는 경우, 메모리 상한에 기본값을 설정하는 것이 좋다. -다음은 리소스 쿼터가 네임스페이스에 적용하는 두 가지 제한 사항이다. +다음은 리소스 쿼터가 네임스페이스에 적용하는 세 가지 제한 사항이다. * 네임스페이스에서 실행되는 모든 파드에 대해, 모든 컨테이너에 메모리 상한이 있어야 한다. (파드의 모든 컨테이너에 대해 메모리 상한을 지정하면, From 578c2e815d18439055887650f160f32430d7db50 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Mon, 18 Jul 2022 12:52:07 +0900 Subject: [PATCH 018/202] [ko] Update outdated files in dev-1.24-ko.2 (M65-M70) --- content/ko/docs/setup/_index.md | 10 +- .../docs/setup/best-practices/certificates.md | 2 +- .../setup/production-environment/_index.md | 297 +++++++++--------- .../container-runtimes.md | 125 ++++++-- .../tools/kubeadm/install-kubeadm.md | 23 +- .../production-environment/tools/kubespray.md | 7 +- 6 files changed, 262 insertions(+), 202 deletions(-) diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 3c6013c590..3334e08638 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -27,6 +27,13 @@ card: [쿠버네티스를 다운로드](/releases/download/)하여 로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다. +`kube-apiserver`나 `kube-proxy`와 같은 몇몇 [쿠버네티스 컴포넌트](/releases/download/)들은 +클러스터 내에서 [컨테이너 이미지](/releases/download/#container-images)를 통해 배포할 수 있다. + +쿠버네티스 컴포넌트들은 가급적 컨테이너 이미지로 실행하는 것을 **추천**하며, +이를 통해 쿠버네티스가 해당 컴포넌트들을 관리하도록 한다. +컨테이너를 구동하는 컴포넌트(특히 kubelet)는 여기에 속하지 않는다. + 쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과 같은 매니지드 서비스를 선택할 수도 있다. 광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 @@ -60,4 +67,5 @@ card: 쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는 다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다. -- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다. + +- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/concepts/windows/)를 살펴본다. diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 2774fca3e0..7949db8ffc 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -23,7 +23,7 @@ weight: 40 * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서 * API 서버가 kubelet과 통신하기 위한 - kubelet [서버 인증서](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates) + kubelet [서버 인증서](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) * API 서버 엔드포인트를 위한 서버 인증서 * API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서 * API 서버에서 kubelet과 통신을 위한 클라이언트 인증서 diff --git a/content/ko/docs/setup/production-environment/_index.md b/content/ko/docs/setup/production-environment/_index.md index e14fce8baa..e369d3ed69 100644 --- a/content/ko/docs/setup/production-environment/_index.md +++ b/content/ko/docs/setup/production-environment/_index.md @@ -28,29 +28,29 @@ no_list: true 다음 이슈에 의해 어떻게 영향을 받는지 고려해야 한다. - *가용성*: 단일 머신 쿠버네티스 [학습 환경](/ko/docs/setup/#학습-환경)은 SPOF(Single Point of Failure, 단일 장애 지점) 이슈를 갖고 있다. -고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다. + 고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다. - 컨트롤 플레인과 워크 노드를 분리 - 컨트롤 플레인 구성요소를 여러 노드에 복제 - 클러스터의 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}로 가는 트래픽을 로드밸런싱 - 워커 노드를 충분히 운영하거나, 워크로드 변경에 따라 빠르게 제공할 수 있도록 보장 - *스케일링*: 프로덕션 쿠버네티스 환경에 들어오는 요청의 양의 -일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 -마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 -계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, -컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 -잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다. + 일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 + 마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 + 계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, + 컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 + 잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다. - *보안 및 접근 관리*: 학습을 위한 쿠버네티스 클러스터에는 -완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 -두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 -접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다. -역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및 -기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 -액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. -[정책](/ko/docs/concepts/policy/)과 -[컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를 -관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다. + 완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 + 두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 + 접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다. + 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및 + 기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 + 액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. + [정책](/ko/docs/concepts/policy/)과 + [컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를 + 관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다. 쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) @@ -59,16 +59,16 @@ no_list: true 다음과 같은 옵션이 있다. - *서버리스*: 클러스터를 전혀 관리하지 않고 -타사 장비에서 워크로드를 실행하기만 하면 된다. -CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다. + 타사 장비에서 워크로드를 실행하기만 하면 된다. + CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다. - *관리형 컨트롤 플레인*: 쿠버네티스 서비스 공급자가 -클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다. + 클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다. - *관리형 워커 노드*: 필요에 맞는 노드 풀을 정의하면, -쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 -필요 시 업그레이드 제공을 보장한다. + 쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 + 필요 시 업그레이드 제공을 보장한다. - *통합*: 쿠버네티스를 스토리지, 컨테이너 레지스트리, -인증 방법 및 개발 도구와 같이 -사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다. + 인증 방법 및 개발 도구와 같이 + 사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다. 프로덕션 쿠버네티스 클러스터를 직접 구축하든 파트너와 협력하든, 요구 사항이 *컨트롤 플레인*, *워커 노드*, @@ -99,52 +99,52 @@ CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금 다음 사항들을 고려한다. - *배포 도구 선택*: kubeadm, kops, kubespray와 같은 도구를 이용해 -컨트롤 플레인을 배포할 수 있다. -[배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서 -여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. -배포 시, 다양한 -[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다. + 컨트롤 플레인을 배포할 수 있다. + [배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서 + 여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. + 배포 시, 다양한 + [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다. - *인증서 관리*: 컨트롤 플레인 서비스 간의 보안 통신은 인증서를 사용하여 구현된다. -인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. -[PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서 -상세 사항을 확인한다. + 인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. + [PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서 + 상세 사항을 확인한다. - *apiserver를 위한 로드밸런서 구성*: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에 -외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. -[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서 -상세 사항을 확인한다. + 외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. + [외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서 + 상세 사항을 확인한다. - *etcd 서비스 분리 및 백업*: etcd 서비스는 -다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, -또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. -etcd는 클러스터 구성 데이터를 저장하므로 -필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다. -[etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다. -[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 -[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 -상세 사항을 확인한다. + 다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, + 또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. + etcd는 클러스터 구성 데이터를 저장하므로 + 필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다. + [etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다. + [쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 + [kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 + 상세 사항을 확인한다. - *다중 컨트롤 플레인 시스템 구성*: 고가용성을 위해, -컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. -컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, -각 서비스는 최소 3대의 머신에서 실행되어야 한다. -그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 -각 서비스 복제본 요청이 보장된다. -스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다. -일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 -[Raft](https://raft.github.io/) 합의 알고리즘을 설정한다. -리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다. + 컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. + 컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, + 각 서비스는 최소 3대의 머신에서 실행되어야 한다. + 그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 + 각 서비스 복제본 요청이 보장된다. + 스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다. + 일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 + [Raft](https://raft.github.io/) 합의 알고리즘을 설정한다. + 리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다. - *다중 영역(zone)으로 확장*: 클러스터를 항상 사용 가능한 상태로 유지하는 것이 중요하다면 -여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 -클러스터를 만드는 것이 좋다. -영역의 그룹을 지역(region)이라고 한다. -동일한 지역의 여러 영역에 클러스터를 분산하면 -하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다. -[여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다. + 여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 + 클러스터를 만드는 것이 좋다. + 영역의 그룹을 지역(region)이라고 한다. + 동일한 지역의 여러 영역에 클러스터를 분산하면 + 하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다. + [여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다. - *구동 중인 기능 관리*: 클러스터를 계속 유지하려면, -상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. -예를 들어 kubeadm으로 클러스터를 생성한 경우, -[인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와 -[kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다. -[클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서 -더 많은 쿠버네티스 관리 작업을 볼 수 있다. + 상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. + 예를 들어 kubeadm으로 클러스터를 생성한 경우, + [인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와 + [kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다. + [클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서 + 더 많은 쿠버네티스 관리 작업을 볼 수 있다. 컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 보려면, [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), @@ -166,39 +166,36 @@ etcd 백업 계획을 세우려면 워커 노드(간단히 *노드*라고도 함)를 어떤 방법으로 관리할지 고려해야 한다. - *노드 구성하기*: 노드는 물리적 또는 가상 머신일 수 있다. -직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 -적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다. -다음을 고려해야 한다. + 직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 + 적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다. + 다음을 고려해야 한다. - 워크로드의 요구 사항 (노드가 적절한 메모리, CPU, 디스크 속도, 저장 용량을 갖도록 구성) - 일반적인 컴퓨터 시스템이면 되는지, 아니면 GPU, 윈도우 노드, 또는 VM 격리를 필요로 하는 워크로드가 있는지 - *노드 검증하기*: [노드 구성 검증하기](/ko/docs/setup/best-practices/node-conformance/)에서 -노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 -만족하는지 확인하는 방법을 알아본다. + 노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 + 만족하는지 확인하는 방법을 알아본다. - *클러스터에 노드 추가하기*: 클러스터를 자체적으로 관리하는 경우, -머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 -또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. -이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다. -- *클러스터에 윈도우 노드 추가하기*: 윈도우 컨테이너로 구현된 워크로드를 -실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다. -[쿠버네티스에서의 윈도우](/ko/docs/setup/production-environment/windows/)에서 상세 사항을 확인한다. + 머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 + 또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. + 이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다. - *노드 스케일링*: 클러스터가 최종적으로 필요로 하게 될 용량만큼 -확장하는 것에 대한 계획이 있어야 한다. -실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 -[대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다. -만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다. + 확장하는 것에 대한 계획이 있어야 한다. + 실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 + [대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다. + 만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다. - *노드 자동 스케일링*: 대부분의 클라우드 공급자는 -비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 -[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다. -[자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서 -오토스케일러가 어떻게 동작하는지, -[배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서 -각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. -온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 -스크립트를 구성할 수 있는 가상화 플랫폼이 있다. + 비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 + [클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다. + [자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서 + 오토스케일러가 어떻게 동작하는지, + [배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서 + 각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. + 온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 + 스크립트를 구성할 수 있는 가상화 플랫폼이 있다. - *노드 헬스 체크 구성*: 중요한 워크로드의 경우, -해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. -[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) -데몬을 사용하면 노드가 정상인지 확인할 수 있다. + 해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. + [Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) + 데몬을 사용하면 노드가 정상인지 확인할 수 있다. ## 프로덕션 사용자 관리 @@ -215,39 +212,51 @@ etcd 백업 계획을 세우려면 다음과 같은 전략을 선택해야 한다. - *인증*: apiserver는 클라이언트 인증서, 전달자 토큰, 인증 프록시 또는 -HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다. -사용자는 인증 방법을 선택하여 사용할 수 있다. -apiserver는 또한 플러그인을 사용하여 -LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다. -쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 -[인증](/docs/reference/access-authn-authz/authentication/)을 참조한다. -- *인가*: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다. - - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다. - - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다. + HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다. + 사용자는 인증 방법을 선택하여 사용할 수 있다. + apiserver는 또한 플러그인을 사용하여 + LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다. + 쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 + [인증](/docs/reference/access-authn-authz/authentication/)을 참조한다. +- *인가*: 일반 사용자 인가를 위해, + RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 + 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 + 확인할 수 있다. + - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 + 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. + 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. + 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 + 특정 사용자에게 연결할 수 있다. + - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 + 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. + 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), + 그리고 '대상(사용자 또는 그룹)', '리소스 속성', + '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. + 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다. 프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다. -- *인가 모드 설정*: 쿠버네티스 API 서버([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, -*`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다. -예를 들어, (*`/etc/kubernetes/manifests`*에 있는) -*`kube-adminserver.yaml`* 파일 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. -이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다. +- *인가 모드 설정*: 쿠버네티스 API 서버 + ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, + *`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다. + 예를 들어, *`kube-adminserver.yaml`* 파일(*`/etc/kubernetes/manifests`*에 있는) 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. + 이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다. - *사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우)*: RBAC 인증을 사용하는 경우, -사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. -그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다. -자세한 내용은 -[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다. + 사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. + 그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다. + 자세한 내용은 + [인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다. - *속성을 포함하는 정책 생성(ABAC을 사용하는 경우)*: ABAC 인증을 사용하는 경우, -속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 -특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. -[예시](/docs/reference/access-authn-authz/abac/#examples)에서 -더 많은 정보를 확인한다. + 속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 + 특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. + [예시](/docs/reference/access-authn-authz/abac/#examples)에서 + 더 많은 정보를 확인한다. - *어드미션 컨트롤러 도입 고려*: -[웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은 -API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. -웹훅 및 다른 인가 형식을 사용하려면 API 서버에 -[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 -추가해야 한다. + [웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은 + API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. + 웹훅 및 다른 인가 형식을 사용하려면 API 서버에 + [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 + 추가해야 한다. ## 워크로드에 자원 제한 걸기 @@ -256,38 +265,44 @@ API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추 워크로드의 요구 사항을 충족하도록 클러스터를 구성할 때 다음 항목을 고려한다. - *네임스페이스 제한 설정*: 메모리, CPU와 같은 자원의 네임스페이스 별 쿼터를 설정한다. -[메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서 -상세 사항을 확인한다. -[계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여 -제한을 상속할 수도 있다. + [메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서 + 상세 사항을 확인한다. + [계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여 + 제한을 상속할 수도 있다. - *DNS 요청에 대한 대비*: 워크로드가 대규모로 확장될 것으로 예상된다면, -DNS 서비스도 확장할 준비가 되어 있어야 한다. -[클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다. + DNS 서비스도 확장할 준비가 되어 있어야 한다. + [클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다. - *추가적인 서비스 어카운트 생성*: 사용자 계정은 *클러스터*에서 사용자가 무엇을 할 수 있는지 결정하는 반면에, -서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. -기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다. -[서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 -새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다. - - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 예시를 확인한다. - - 서비스 어카운트에 RBAC 권한을 할당한다. [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 상세 사항을 확인한다. + 서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. + 기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다. + [서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 + 새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다. + - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. + [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 + 예시를 확인한다. + - 서비스 어카운트에 RBAC 권한을 할당한다. + [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 + 상세 사항을 확인한다. ## {{% heading "whatsnext" %}} - 프로덕션 쿠버네티스를 직접 구축할지, -아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는 -[쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다. + 아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는 + [쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다. - 클러스터를 직접 구축한다면, -[인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, -[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 -[API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) -등의 기능에 대한 고가용성을 -어떻게 보장할지를 계획한다. -- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/), [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 -하나를 선택한다. + [인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, + [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 + [API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) + 등의 기능에 대한 고가용성을 + 어떻게 보장할지를 계획한다. +- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), + [kops](/ko/docs/setup/production-environment/tools/kops/), + [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 + 하나를 선택한다. - [인증](/docs/reference/access-authn-authz/authentication/) 및 -[인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 -사용자 관리 방법을 구성한다. + [인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 + 사용자 관리 방법을 구성한다. - [자원 제한](/ko/docs/tasks/administer-cluster/manage-resources/), -[DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), -[서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 -애플리케이션 워크로드의 실행에 대비한다. + [DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), + [서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 + 애플리케이션 워크로드의 실행에 대비한다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 6f375e081b..02398df6a7 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -36,7 +36,7 @@ _dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 더 이상 쿠버네티스에 포함되지 않는다(이 제거는 v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다). 이 제거가 어떻게 영향을 미치는지 알아보려면 -[Dockershim 사용 중단이 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. +[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다. dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면, [dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다. @@ -46,6 +46,41 @@ v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 +## 필수 요소들 설치 및 구성하기 + +다음 단계에서는 리눅스의 쿠버네티스 노드를 위한 일반적인 설정들을 적용한다. + +만약 필요하지 않다고 생각한다면 몇몇 설정들은 넘어가도 무방하다. + +더 자세한 정보는, [네트워크 플러그인 요구사항](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements)이나 각자 사용 중인 컨테이너 런타임에 해당하는 문서를 확인한다. + +### IPv4를 포워딩하여 iptables가 브리지된 트래픽을 보게 하기 + +`lsmod | grep br_netfilter`를 실행하여 `br_netfilter` 모듈이 로드되었는지 확인한다. + +명시적으로 로드하려면, `sudo modprobe br_netfilter`를 실행한다. + +리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables`가 1로 설정되어 있는지 확인한다. 예를 들어, + +```bash +cat <}} +{{% tab name="Linux" %}} +`/etc/containerd/config.toml` 경로에서 파일을 찾을 수 있음. +{{% /tab %}} +{{< tab name="Windows" >}} +`C:\Program Files\containerd\config.toml` 경로에서 파일을 찾을 수 있음. +{{< /tab >}} +{{< /tabs >}} 리눅스에서, containerd를 위한 기본 CRI 소켓은 `/run/containerd/containerd.sock`이다. 윈도우에서, 기본 CRI 엔드포인트는 `npipe://./pipe/containerd-containerd`이다. @@ -185,6 +197,14 @@ kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true ``` +{{< note >}} +만약 containerd를 패키지(RPM, `.deb` 등)를 통해 설치하였다면, +CRI integration 플러그인은 기본적으로 비활성화되어 있다. + +쿠버네티스에서 containerd를 사용하기 위해서는 CRI support가 활성화되어 있어야 한다. +`cri`가 `/etc/containerd/config.toml` 파일 안에 있는 `disabled_plugins` 목록에 포함되지 않도록 주의하자. +만약 해당 파일을 변경하였다면, `containerd`를 다시 시작한다. +{{< /note >}} 이 변경 사항을 적용하려면, containerd를 재시작한다. @@ -193,7 +213,19 @@ sudo systemctl restart containerd ``` kubeadm을 사용하는 경우, -[kubelet용 cgroup 드라이버](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#컨트롤-플레인-노드에서-kubelet이-사용하는-cgroup-드라이버-구성)를 수동으로 구성한다. +[kubelet용 cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver)를 수동으로 구성한다. + +#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd} + +[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서 +아래와 같이 샌드박스 이미지를 덮어쓸 수 있다. + +```toml +[plugins."io.containerd.grpc.v1.cri"] + sandbox_image = "k8s.gcr.io/pause:3.2" +``` + +설정 파일을 변경하는 경우 역시 `systemctl restart containerd`를 통해 `containerd`를 재시작해야 한다. ### CRI-O @@ -221,6 +253,19 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다. +#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-o} + +[CRI-O 설정](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md)에서 +아래와 같이 샌드박스 이미지를 덮어쓸 수 있다. + +```toml +[crio.image] +pause_image="registry.k8s.io/pause:3.6" +``` + +이 옵션은 `systemctl reload crio` 혹은 `crio` 프로세스에 `SIGHUP`을 보내 변경사항을 적용하기 위한 +live configuration reload 기능을 지원한다. + ### 도커 엔진 {#docker} {{< note >}} @@ -237,6 +282,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다. `cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다. +#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd} + +`cri-dockerd` 어댑터는, +파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다. +해당 커맨드라인 인자는 `--pod-infra-container-image`이다. + ### 미란티스 컨테이너 런타임 {#mcr} [미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며 @@ -251,6 +302,12 @@ CRI-O의 경우, CRI 소켓은 기본적으로 `/var/run/crio/crio.sock`이다. CRI 소켓의 경로를 찾으려면 `cri-docker.socket`라는 이름의 systemd 유닛을 확인한다. +#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd-mcr} + +`cri-dockerd` 어댑터는, +파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다. +해당 커맨드라인 인자는 `--pod-infra-container-image`이다. + ## {{% heading "whatsnext" %}} 컨테이너 런타임과 더불어, 클러스터에는 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 6d11250ac8..0f57094232 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -45,26 +45,6 @@ card: 네트워크 어댑터가 두 개 이상이고, 쿠버네티스 컴포넌트가 디폴트 라우트(default route)에서 도달할 수 없는 경우, 쿠버네티스 클러스터 주소가 적절한 어댑터를 통해 이동하도록 IP 경로를 추가하는 것이 좋다. -## iptables가 브리지된 트래픽을 보게 하기 - -`br_netfilter` 모듈이 로드되었는지 확인한다. `lsmod | grep br_netfilter` 를 실행하면 된다. 명시적으로 로드하려면 `sudo modprobe br_netfilter` 를 실행한다. - -리눅스 노드의 iptables가 브리지된 트래픽을 올바르게 보기 위한 요구 사항으로, `sysctl` 구성에서 `net.bridge.bridge-nf-call-iptables` 가 1로 설정되어 있는지 확인해야 한다. 다음은 예시이다. - -```bash -cat < -이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Packet(베어메탈), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다. +이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다. Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다. @@ -46,7 +46,7 @@ Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 * 아래 클라우드 제공 업체를 위한 [Terraform](https://www.terraform.io/) 스크립트: * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack) - * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) + * [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal) ### (2/5) 인벤토리 파일 구성하기 @@ -93,7 +93,8 @@ Kubespray는 클러스터를 관리하기 위한 추가적인 플레이북, _sca ### 클러스터 스케일링하기 -scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자. +scale 플레이북을 실행해 클러스터에 워커 노드를 추가할 수 있다. 더 자세히 알고 싶다면, "[노드 추가하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes)" 문서를 확인하자. +remove-node 플레이북을 실행하면 클러스터로부터 워커 노드를 제거할 수 있다. 더 알고 싶다면 "[노드 제거하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#remove-nodes)" 문서를 확인하자. ### 클러스터 업그레이드 하기 From 1281acc7b6e55d7c9729029dd00e2ce6ea083ffe Mon Sep 17 00:00:00 2001 From: Yoon Seo-Yul Date: Mon, 25 Jul 2022 23:20:30 +0900 Subject: [PATCH 019/202] [ko] Update outdated files dev-1.24-ko.2 (M44-M50) Apply suggestions from code review Co-authored-by: Yoon --- content/ko/docs/contribute/_index.md | 7 + content/ko/docs/contribute/advanced.md | 2 +- .../docs/contribute/new-content/open-a-pr.md | 170 ++++++++++-------- .../ko/docs/contribute/participate/_index.md | 5 +- .../participate/roles-and-responsibilities.md | 2 +- .../docs/contribute/review/for-approvers.md | 4 +- 6 files changed, 114 insertions(+), 76 deletions(-) diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 62b98b68d3..4676db9617 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -18,8 +18,15 @@ card: {{< note >}} 일반적인 쿠버네티스에 기여하는 방법에 대한 자세한 내용은 [기여자 문서](https://www.kubernetes.dev/docs/)를 참고한다. + +또한, 쿠버네티스 기여에 대한 내용은 +{{< glossary_tooltip text="CNCF" term_id="cncf" >}} +[문서](https://contribute.cncf.io/contributors/projects/#kubernetes) +를 참고한다. {{< /note >}} +--- + 이 웹사이트는 [쿠버네티스 SIG Docs](/ko/docs/contribute/#sig-docs에-참여)에 의해서 관리됩니다. 쿠버네티스 문서 기여자들은 diff --git a/content/ko/docs/contribute/advanced.md b/content/ko/docs/contribute/advanced.md index e40ebc71c1..047dfe37a8 100644 --- a/content/ko/docs/contribute/advanced.md +++ b/content/ko/docs/contribute/advanced.md @@ -136,7 +136,7 @@ SIG Docs의 공동 의장 역할을 할 수 있다. 다음과 같은 책임을 가진다. - SIG Docs가 우수한 문서화를 통해 개발자의 행복을 극대화하는 데 집중한다. -- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다. +- 스스로가 [커뮤니티 행동 강령](https://github.com/cncf/foundation/blob/main/code-of-conduct-languages/ko.md)을 준수하여 예를 보이고, SIG 멤버들이 지킬 수 있도록 책임을 진다. - 기여에 대한 새로운 지침을 확인하여 SIG에 대한 모범 사례를 배우고 설정한다. - SIG 회의를 예약하고 진행한다. 주간 상태 업데이트, 브랜치별 회고/기획 세션과 필요에 따라 그 외 세션을 진행한다. - KubeCon 이벤트 및 기타 컨퍼런스에서 문서 스프린트를 스케줄링하고 진행한다. diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 0871800715..daf6932a16 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -15,13 +15,15 @@ card: [새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다. {{< /note >}} -새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다. - -변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. - -변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 컴퓨터에서 로컬로 변경하는 방법을 배운다. +새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. +[시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 +모든 요구 사항을 준수해야 한다. +변경 사항이 적거나, git에 익숙하지 않은 경우, +[GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자. +변경 사항이 많으면, [로컬 포크에서 작업하기](#fork-the-repo)를 읽고 +컴퓨터에서 로컬로 변경하는 방법을 배운다. @@ -61,7 +63,7 @@ class tasks,tasks2 white class id1 k8s {{}} -***그림 - GitHub 상에서 PR을 여는 단계*** +그림 - GitHub 상에서 PR을 여는 단계 1. 이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다. 페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다. @@ -91,7 +93,8 @@ class id1 k8s - **Allow edits from maintainers** 체크박스는 선택된 상태로 둔다. {{< note >}} - PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다. + PR 설명은 리뷰어가 변경 사항을 이해하는 데 유용한 방법이다. + 자세한 내용은 [PR 열기](#open-a-pr)를 참고한다. {{}} 7. **Create pull request** 를 선택한다. @@ -120,7 +123,8 @@ GitHub 사용자 이름을 코멘트로 남긴다. git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 로컬 포크로 작업한다. -컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다. +컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. +git UI 애플리케이션을 사용할 수도 있다. 아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다. @@ -151,7 +155,8 @@ class 1,2,3,3a,4,5,6 grey class S,T spacewhite class changes,changes2 white {{}} -***그림 - 로컬 포크에서 변경 사항 작업하기*** + +그림 - 로컬 포크에서 변경 사항 작업하기 ### kubernetes/website 리포지터리 포크하기 @@ -201,7 +206,10 @@ class changes,changes2 white 이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다. {{< note >}} - 이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다. + 이 워크플로는 + [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md) + 와 다르다. + 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다. {{< /note >}} ### 브랜치 만들기 @@ -211,14 +219,16 @@ class changes,changes2 white - 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다. - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다. - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다. - - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. + - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. + 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는, 해당 작업을 위해 작성된 특정 기능 브랜치를 사용한다. 브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다. -2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다. +2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. + 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다. ```bash git checkout -b upstream/main @@ -268,7 +278,8 @@ class changes,changes2 white ``` {{< note >}} - 커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. 나중에 풀 리퀘스트 설명에 추가할 + 커밋 메시지에 [GitHub 키워드](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)를 사용하지 말자. + 나중에 풀 리퀘스트 설명에 추가할 수 있다. {{< /note >}} @@ -280,39 +291,34 @@ class changes,changes2 white ### 로컬에서 변경 사항 미리보기 {#preview-locally} -변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. 미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. +변경 사항을 푸시하거나 풀 리퀘스트를 열기 전에 변경 사항을 로컬에서 미리 보는 것이 좋다. +미리보기를 사용하면 빌드 오류나 마크다운 형식 문제를 알아낼 수 있다. -website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. 도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, 디버깅에 유용할 수 있다. +website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 수 있다. +도커 이미지 빌드는 느리지만 [Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 표시하므로, +디버깅에 유용할 수 있다. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo 컨테이너" %}} {{< note >}} -아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. 이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다. +아래 명령은 도커를 기본 컨테이너 엔진으로 사용한다. +이 동작을 무시하려면 `CONTAINER_ENGINE` 환경 변수를 설정한다. {{< /note >}} 1. 로컬에서 이미지를 빌드한다. + _Hugo 도구 자체에 대한 변경을 테스트하는 경우에만 이 단계가 필요하다._ - ```bash - # docker 사용(기본값) - make container-image - - ### 또는 ### - - # podman 사용 - CONTAINER_ENGINE=podman make container-image + ```shell + # 터미널에서 명령 실행 (필요에 따라) + make container-serve ``` -2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다. +2. 컨테이너에서 Hugo를 시작한다. - ```bash - # docker 사용(기본값) + ```shell + # 터미널에서 실행 make container-serve - - ### 또는 ### - - # podman 사용 - CONTAINER_ENGINE=podman make container-serve ``` 3. 웹 브라우저에서 `https://localhost:1313` 로 이동한다. Hugo는 @@ -326,18 +332,19 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. -1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. +1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 + [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. 2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다. -테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. + 테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. - ```bash + ```shell git submodule update --init --recursive --depth 1 ``` 3. 터미널에서, 쿠버네티스 website 리포지터리로 이동하여 Hugo 서버를 시작한다. - ```bash + ```shell cd /website hugo server --buildFuture ``` @@ -354,6 +361,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 ### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr} 아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다. + @@ -379,7 +387,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 {{}} -***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계*** + +그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계 1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다. 2. **New Pull Request** 를 선택한다. @@ -387,29 +396,36 @@ class first,second white 4. **head repository** 드롭다운 메뉴에서, 포크를 선택한다. 5. **compare** 드롭다운 메뉴에서, 브랜치를 선택한다. 6. **Create Pull Request** 를 선택한다. -7. 풀 리퀘스트에 대한 설명을 추가한다. +`. 풀 리퀘스트에 대한 설명을 추가한다. + - **Title**(50자 이하): 변경 사항에 대한 의도를 요약한다. - **Description**: 변경 사항을 자세히 설명한다. - - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다. - - 구체적인 내용에 대한 조언이 필요한 경우, 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다. -8. **Create pull request** 버튼을 선택한다. + - 관련된 GitHub 이슈가 있는 경우, `Fixes #12345` 또는 `Closes #12345` 를 설명에 포함한다. + 이렇게 하면 GitHub의 자동화 기능이 PR을 병합한 후 언급된 이슈를 닫는다. + 다른 관련된 PR이 있는 경우, 이들 PR도 연결한다. + - 구체적인 내용에 대한 조언이 필요한 경우, + 원하는 질문을 리뷰어가 생각해볼 수 있도록 설명에 포함한다. + +7. **Create pull request** 버튼을 선택한다. 축하한다! 여러분의 풀 리퀘스트가 [풀 리퀘스트](https://github.com/kubernetes/website/pulls)에 열렸다. - -PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. +PR을 연 후, GitHub는 자동 테스트를 실행하고 +[Netlify](https://www.netlify.com/)를 사용하여 미리보기를 배포하려고 시도한다. - Netlify 빌드가 실패하면, 자세한 정보를 위해 **Details** 를 선택한다. - - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. + - Netlify 빌드가 성공하면, **Details** 를 선택하면 변경 사항이 적용된 쿠버네티스 website의 커밋하기 + 직전의 버전(staged version)이 열린다. 리뷰어가 변경 사항을 확인하는 방법이다. -또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. 자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다. +또한 GitHub는 리뷰어에게 도움을 주기 위해 PR에 레이블을 자동으로 할당한다. 필요한 경우 직접 추가할 수도 있다. +자세한 내용은 [이슈 레이블 추가와 제거](/ko/docs/contribute/review/for-approvers/#이슈-레이블-추가와-제거)를 참고한다. ### 로컬에서 피드백 해결 1. 변경한 후, 이전 커밋을 수정한다. - ```bash + ```shell git commit -a --amend ``` @@ -421,7 +437,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 3. `git push origin ` 를 사용해서 변경 사항을 푸시하고 Netlify 테스트를 다시 실행한다. {{< note >}} - 수정하는 대신 `git commit -m` 을 사용하는 경우, 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다. + 수정하는 대신 `git commit -m` 을 사용하는 경우, + 병합하기 전에 [커밋을 스쿼시](#커밋-스쿼시하기)해야 한다. {{< /note >}} #### 리뷰어의 변경 @@ -430,35 +447,38 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 1. 원격 포크에서 커밋을 가져오고 작업 브랜치를 리베이스한다. - ```bash + ```shell git fetch origin git rebase origin/ ``` 2. 리베이스한 후, 포크에 새로운 변경 사항을 강제로 푸시한다. - ```bash + ```shell git push --force-with-lease origin ``` #### 충돌 병합 및 리베이스 {{< note >}} -자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +자세한 내용은 [Git 브랜치 - 기본 브랜치와 병합](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), +[고급 병합](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)을 참조하거나, +슬랙 채널 `#sig-docs` 에서 도움을 요청한다. {{< /note >}} -다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. PR의 모든 병합 충돌을 해결해야 한다. +다른 기여자가 다른 PR에서 동일한 파일에 대한 변경 사항을 커밋하면, 병합 충돌이 발생할 수 있다. +PR의 모든 병합 충돌을 해결해야 한다. 1. 포크를 업데이트하고 로컬 브랜치를 리베이스한다. - ```bash + ```shell git fetch origin git rebase origin/ ``` 그런 다음 포크에 변경 사항을 강제로 푸시한다. - ```bash + ```shell git push --force-with-lease origin ``` @@ -477,7 +497,8 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 이 명령의 결과에 여러 파일이 충돌된 것으로 표시된다. -4. 충돌하는 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. 충돌을 해결하고 충돌 마커를 삭제한다. +4. 충돌한 각 파일을 열고 충돌 마커(`>>>`,`<<<` 그리고 `===`)를 찾는다. + 충돌을 해결하고 충돌 마커를 삭제한다. {{< note >}} 자세한 내용은 [충돌이 표시되는 방법](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented)을 참고한다. @@ -485,12 +506,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 5. 변경 세트에 파일을 추가한다. - ```bash + ```shell git add ``` + 6. 리베이스를 계속한다. - ```bash + ```shell git rebase --continue ``` @@ -500,7 +522,7 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. 8. 브랜치를 포크에 강제로 푸시한다. - ```bash + ```shell git push --force-with-lease origin ``` @@ -509,10 +531,13 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. ### 커밋 스쿼시하기 {{< note >}} -자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, 슬랙 채널 `#sig-docs` 에서 도움을 요청한다. +자세한 내용은 [Git 도구 - 히스토리 다시 쓰기](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)를 참고하거나, +슬랙 채널 `#sig-docs` 에서 도움을 요청한다. {{< /note >}} -PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 커밋 수를 확인할 수 있다. +PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 단일 커밋으로 스쿼시해야 한다. +PR의 **Commits** 탭에서 또는 `git log` 명령을 로컬에서 실행하여 +커밋 수를 확인할 수 있다. {{< note >}} 여기서는 `vim` 을 커맨드 라인 텍스트 편집기로 사용하는 것을 가정한다. @@ -520,15 +545,16 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 1. 대화식 리베이스를 시작한다. - ```bash + ```shell git rebase -i HEAD~ ``` - 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. + 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. + `HEAD~` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. 출력은 다음과 비슷하다. - ```bash + ```none pick d875112ca Original commit pick 4fa167b80 Address feedback 1 pick 7d54e15ee Address feedback 2 @@ -540,7 +566,9 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 # 이 행들은 순서를 바꿀 수 있다. 이들은 위에서 아래로 실행된다. ``` - 출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다. + 출력의 첫 번째 섹션에는 리베이스의 커밋이 나열된다. + 두 번째 섹션에는 각 커밋에 대한 옵션이 나열되어 있다. + `pick` 단어를 바꾸면 리베이스가 완료되었을 때 커밋 상태가 변경된다. 리베이스를 하는 목적인 `squash` 와 `pick` 에 집중한다. @@ -552,7 +580,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 다음의 원본 텍스트를 변경한다. - ```bash + ```none pick d875112ca Original commit pick 4fa167b80 Address feedback 1 pick 7d54e15ee Address feedback 2 @@ -560,13 +588,14 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 아래와 같이 변경한다. - ```bash + ```none pick d875112ca Original commit squash 4fa167b80 Address feedback 1 squash 7d54e15ee Address feedback 2 ``` - 이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. 타임라인의 일부로 `d875112ca Original commit` 만 남긴다. + 이것은 커밋 `4fa167b80 Address feedback 1` 과 `7d54e15ee Address feedback 2` 를 `d875112ca Original commit` 으로 스쿼시한다. + 타임라인의 일부로 `d875112ca Original commit` 만 남긴다. 3. 파일을 저장하고 종료한다. @@ -578,14 +607,15 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 ## 다른 리포지터리에 기여하기 -[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. 이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 또는 코드 주석과 같은 문서가 포함되어 있다. +[쿠버네티스 프로젝트](https://github.com/kubernetes)에는 50개 이상의 리포지터리가 포함되어 있다. +이러한 리포지터리에는 사용자용 도움말 텍스트, 오류 메시지, API 레퍼런스 +또는 코드 주석과 같은 문서가 포함되어 있다. 개선하려는 텍스트가 보이면, GitHub을 사용하여 쿠버네티스 조직의 모든 리포지터리를 검색한다. 이를 통해 어디에 이슈나 PR을 제출할지를 파악할 수 있다. -각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 -제기하거나 PR을 제출하기 전에, 그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 -`code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다. +각 리포지터리에는 고유한 프로세스와 절차가 있다. 여러분이 이슈를 제기하거나 PR을 제출하기 전에, +그 리포지터리의 `README.md`, `CONTRIBUTING.md` 그리고 `code-of-conduct.md`(만약 이들 문서가 있다면)를 읽어본다. 대부분의 리포지터리에는 이슈와 PR 템플릿이 사용된다. 팀의 프로세스에 대한 느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때 diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index 9f874351b0..80983b9215 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -93,9 +93,8 @@ PR 소유자에게 조언하는데 활용된다. ## 병합 작업 방식 -풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 -브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의 -품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. +풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. +게시된 콘텐츠의 품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. 작동 방식은 다음과 같다. - 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 091dac7059..f816a12191 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D - [슬랙](https://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. -[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다. +[CLA에 서명](https://github.com/kubernetes/community/blob/master/CLA.md) 후에 누구나 다음을 할 수 있다. - 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. - 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다. diff --git a/content/ko/docs/contribute/review/for-approvers.md b/content/ko/docs/contribute/review/for-approvers.md index 5b99cd02a6..3ded883231 100644 --- a/content/ko/docs/contribute/review/for-approvers.md +++ b/content/ko/docs/contribute/review/for-approvers.md @@ -181,7 +181,7 @@ SIG Docs가 처리 방법을 문서화할 정도로 다음과 같은 유형의 ### 블로그 이슈 -[쿠버네티스 블로그](https://kubernetes.io/blog/) 항목은 시간이 지남에 따라 +[쿠버네티스 블로그](/blog/) 항목은 시간이 지남에 따라 구식이 될 것으로 예상한다. 따라서, 1년 미만의 블로그 항목만 유지 관리한다. 1년이 지난 블로그 항목과 관련된 이슈일 경우, 수정하지 않고 이슈를 닫는다. @@ -221,3 +221,5 @@ https://github.com/kubernetes/kubernetes 에서 문서에 대한 이슈인 경우 이 이슈를 다시 여십시오. ``` + + From 4d92fef330099bc888cdd0a8b22ab41dc5d7e614 Mon Sep 17 00:00:00 2001 From: KimDoubleB Date: Wed, 20 Jul 2022 01:05:04 +0900 Subject: [PATCH 020/202] Update outdated files dev-1.24-ko.2 (M11-M20) --- .../organize-cluster-access-kubeconfig.md | 9 +- .../ko/docs/concepts/configuration/secret.md | 39 +++-- .../docs/concepts/extend-kubernetes/_index.md | 144 +++++++++++++----- .../compute-storage-net/device-plugins.md | 2 +- .../compute-storage-net/network-plugins.md | 41 +++-- .../concepts/extend-kubernetes/operator.md | 2 + .../docs/concepts/overview/kubernetes-api.md | 2 +- .../overview/working-with-objects/names.md | 2 +- 8 files changed, 161 insertions(+), 80 deletions(-) diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 48b3c9a960..eb44669be0 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -18,7 +18,7 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 {{< /note >}} {{< warning >}} -신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. +신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. 신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다. {{< /warning>}} @@ -150,16 +150,16 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치 ## 프록시 -다음과 같이 kubeconfig 파일에 `proxy-url`을 설정하여 `kubectl`이 프록시를 거치도록 설정할 수 있다. +다음과 같이 kubeconfig 파일에서 `proxy-url`를 사용하여 `kubectl`이 각 클러스터마다 프록시를 거치도록 설정할 수 있다. ```yaml apiVersion: v1 kind: Config -proxy-url: https://proxy.host:3128 - clusters: - cluster: + proxy-url: http://proxy.example.org:3128 + server: https://k8s.example.org/k8s/clusters/c-xxyyzz name: development users: @@ -168,7 +168,6 @@ users: contexts: - context: name: development - ``` diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 9591c47220..24728c37b0 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -247,6 +247,8 @@ API 크리덴셜이 [TokenRequest](/docs/reference/kubernetes-api/authentication 예를 들어, 영원히 만료되지 않는 토큰이 필요한 경우에 활용할 수 있다. 그러나, 이렇게 하기보다는 API 접근에 필요한 토큰을 얻기 위해 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 서브리소스를 사용하는 것을 권장한다. +`TokenRequest` API로부터 토큰을 얻기 위해 +[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다. {{< /note >}} #### 특정 경로에 대한 시크릿 키 투영하기 @@ -887,14 +889,29 @@ empty-secret Opaque 0 2m6s `kubernetes.io/service-account-token` 시크릿 타입은 {{< glossary_tooltip text="서비스 어카운트" term_id="service-account" >}}를 확인하는 -토큰을 저장하기 위해서 사용한다. +토큰 자격증명을 저장하기 위해서 사용한다. + +1.22 버전 이후로는 이러한 타입의 시크릿은 더 이상 파드에 자격증명을 마운트하는 데 사용되지 않으며, +서비스 어카운트 토큰 시크릿 오브젝트를 사용하는 대신 +[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 통해 토큰을 얻는 것이 추천된다. +`TokenRequest` API에서 얻은 토큰은 제한된 수명을 가지며 다른 API 클라이언트에서 읽을 수 없기 때문에 +시크릿 오브젝트에 저장된 토큰보다 더 안전하다. +`TokenRequest` API에서 토큰을 얻기 위해서 +[`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) 커맨드를 사용할 수 있다. + +토큰을 얻기 위한 `TokenRequest` API를 사용할 수 없는 경우에는 +서비스 어카운트 토큰 시크릿 오브젝트를 생성할 수 밖에 없으나, +이는 만료되지 않는 토큰 자격증명을 읽기 가능한 API 오브젝트로 +지속되는 보안 노출 상황을 감수할 수 있는 경우에만 생성해야 한다. + 이 시크릿 타입을 사용할 때는, `kubernetes.io/service-account.name` 어노테이션이 존재하는 -서비스 어카운트 이름으로 설정되도록 해야 한다. -쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 +서비스 어카운트 이름으로 설정되도록 해야 한다. 만약 서비스 어카운트와 +시크릿 오브젝트를 모두 생성하는 경우, 서비스 어카운트를 먼저 생성해야만 한다. + +시크릿이 생성된 후, 쿠버네티스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 `kubernetes.io/service-account.uid` 어노테이션 및 -`data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채우며, -이들은 인증 토큰을 보관한다. +인증 토큰을 보관하고 있는 `data` 필드의 `token` 키와 같은 몇 가지 다른 필드들을 채운다. 다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다. @@ -911,17 +928,11 @@ data: extra: YmFyCg== ``` -`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을 -생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스 -어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다. - -이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나 -기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만 -필요하다면, 이것이 권장되는 워크플로우이다. +시크릿을 만든 후, 쿠버네티스가 `data` 필드에 `token` 키를 채울 때까지 기다린다. [서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면 서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다. -또한 파드에서 서비스 어카운트를 참조하는 방법을 +또한 파드에서 서비스 어카운트 자격증명을 참조하는 방법에 대한 정보는 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)의 `automountServiceAccountToken` 필드와 `serviceAccountName` 필드를 통해 확인할 수 있다. @@ -982,7 +993,7 @@ kubectl create secret docker-registry secret-tiger-docker \ ``` 이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다. -다음 명령으로 이 새 시크릿에서 `.data.dockercfgjson` 필드를 덤프하고 +다음 명령으로 이 새 시크릿에서 `.data.dockerconfigjson` 필드를 덤프하고 base64로 디코드하면, ```shell diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index a00bc89cc4..272f45e2f4 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -17,14 +17,14 @@ no_list: true -쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 -쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가 -거의 없다. +쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 쿠버네티스 프로젝트를 +포크하거나 코드에 패치를 제출할 필요가 거의 없다. 이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다. 쿠버네티스 클러스터를 업무 환경의 요구에 맞게 조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. -잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 +잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 +쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 어떤 익스텐션(extension) 포인트와 패턴이 있는지, 그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다. @@ -32,11 +32,14 @@ no_list: true ## 개요 -사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. +사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 +포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 +나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. ## 구성 -*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. +*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 +각 바이너리 별로 문서화되어 있다. * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) @@ -44,9 +47,22 @@ no_list: true * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). -호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. +호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 +플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 +가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 +쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 +시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. -[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다. +[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), +[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/), +[네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 +역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 +*빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 +일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 +선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 +구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 있다. 또한, 이들 API가 안정적인 +경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 +사용할 수 있다. 이러한 이유로 인해 *구성 파일* 과 *플래그* 보다 선호된다. ## 익스텐션 @@ -70,10 +86,9 @@ no_list: true 컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음 오브젝트의 `.status`를 업데이트 한다. -컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 -원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 -*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을 -추가한다. +컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 원격 서비스를 호출할 때 +이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 *웹훅 백엔드* 라고 한다. 컨트롤러와 +마찬가지로 웹훅은 장애 지점을 추가한다. 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. @@ -95,15 +110,35 @@ kubectl에서 사용한다. ![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png) -1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. -2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다. -3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. -4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다. -5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. -6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. -7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다. +1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. + [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. + 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. -어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. +1. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, + 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 + [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다. + +1. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 + 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 + 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 + *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. + 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. + +1. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 + 방법이 있다. 이들은 [스케줄러 익스텐션](#스케줄러-익스텐션) 섹션에 설명되어 있다. + +1. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 + 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. + +1. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 + 보이도록 한다. [네트워크 플러그인](#네트워크-플러그인)을 사용하면 다양한 + 파드 네트워킹 구현이 가능하다. + +1. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 + [스토리지 플러그인](#스토리지-플러그인)을 통해 지원될 수 있다. + +어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 +여러 유형의 익스텐션이 포함될 수 있다. ![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png) @@ -112,60 +147,86 @@ kubectl에서 사용한다. ### 사용자 정의 유형 -새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자. +새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 +`kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 +쿠버네티스에 커스텀 리소스를 추가하자. 애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다. -커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다. +커스텀 리소스에 대한 자세한 내용은 +[커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다. ### 새로운 API와 자동화의 결합 -사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. +사용자 정의 리소스 API와 컨트롤 루프의 조합을 +[오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 +특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 +사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. ### 빌트인 리소스 변경 -사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. -API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다. +사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 +새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. +API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API +접근 익스텐션은 영향을 준다. ### API 접근 익스텐션 -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 +다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 +대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 +참고하길 바란다. 이러한 각 단계는 익스텐션 포인트를 제공한다. -쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. +쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 +있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 +확인할 수 있다(웹훅). 이러한 방법은 모두 +[인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. ### 인증 -[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다. - -쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. +[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 +요청하는 클라이언트의 사용자 이름에 매핑한다. +쿠버네티스는 몇 가지 빌트인 인증 방법과 +필요에 맞지 않는 경우 +[인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. ### 인가 -[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. - +[인가](/ko/docs/reference/access-authn-authz/authorization/)는 특정 +사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 +작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 +인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 +통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. ### 동적 어드미션 컨트롤 -요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다. +요청이 승인된 후, 쓰기 작업인 경우 +[어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. +빌트인 단계 외에도 몇 가지 익스텐션이 있다. -* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다. -* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. +* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 + 컨테이너에서 실행할 수 있는 이미지를 제한한다. +* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 + [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 + 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. ## 인프라스트럭처 익스텐션 ### 스토리지 플러그인 -[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면 -Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 -빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. - -FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다. +[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 +사용하면 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이 +볼륨 유형을 마운트 할 수 있다. +FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 +추천하는 방식이다. 자세한 정보는 +[스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 +찾을 수 있다. ### 장치 플러그인 @@ -173,7 +234,6 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou 통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 발견할 수 있게 해준다. - ### 네트워크 플러그인 노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) @@ -192,7 +252,7 @@ FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Ou 스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가 파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는 -[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 +[웹훅](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md)을 지원한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 0459685034..81e753b00a 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -9,7 +9,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.10" state="beta" >}} 쿠버네티스는 시스템 하드웨어 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알리는 데 사용할 수 있는 -[장치 플러그인 프레임워크](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)를 +[장치 플러그인 프레임워크](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md)를 제공한다. 공급 업체는 쿠버네티스 자체의 코드를 커스터마이징하는 대신, 수동 또는 diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index 09f448d83a..a559609810 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -14,6 +14,8 @@ weight: 10 쿠버네티스 {{< skew currentVersion >}} 버전은 클러스터 네트워킹을 위해 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 지원한다. 클러스터와 호환되며 사용자의 요구 사항을 충족하는 CNI 플러그인을 사용해야 한다. 더 넓은 쿠버네티스 생태계에 다양한 플러그인이 존재한다(오픈소스 및 클로즈드 소스). +CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. + [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) 이상의 CNI 스펙과 호환되는 CNI 플러그인을 사용해야 한다. 쿠버네티스 플러그인은 @@ -24,26 +26,37 @@ CNI 스펙 [v1.0.0](https://github.com/containernetworking/cni/blob/spec-v1.0.0/ ## 설치 -CNI 플러그인은 [쿠버네티스 네트워크 모델](/ko/docs/concepts/services-networking/#쿠버네티스-네트워크-모델)을 구현해야 한다. CRI는 자체 CNI 플러그인을 관리한다. 플러그인 사용 시 명심해야 할 두 가지 Kubelet 커맨드라인 파라미터가 있다. +네트워킹 컨텍스트에서 컨테이너 런타임은 kubelet을 위한 CRI 서비스를 제공하도록 구성된 노드의 데몬이다. 특히, 컨테이너 런타임은 쿠버네티스 네트워크 모델을 구현하는 데 필요한 CNI 플러그인을 로드하도록 구성되어야 한다. -* `cni-bin-dir`: Kubelet은 시작할 때 플러그인에 대해 이 디렉터리를 검사한다. -* `network-plugin`: `cni-bin-dir` 에서 사용할 네트워크 플러그인. 플러그인 디렉터리에서 검색한 플러그인이 보고된 이름과 일치해야 한다. CNI 플러그인의 경우, 이는 "cni"이다. +{{< note >}} +쿠버네티스 1.24 이전까지는 `cni-bin-dir`과 `network-plugin` 커맨드 라인 파라미터를 사용해 kubelet이 CNI 플러그인을 관리하게 할 수도 있었다. +이 커맨드 라인 파라미터들은 쿠버네티스 1.24에서 제거되었으며, CNI 관리는 더 이상 kubelet 범위에 포함되지 않는다. + +dockershim 제거 후 문제가 발생하는 경우 +[CNI 플러그인 관련 오류 문제 해결](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)을 참조하자. +{{< /note >}} + +컨테이너 런타임에서 CNI 플러그인을 관리하는 방법에 관한 자세한 내용은 아래 예시와 같은 컨테이너 런타임에 대한 문서를 참조하자. +- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni) +- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) + +CNI 플러그인을 설치하고 관리하는 방법에 관한 자세한 내용은 해당 플러그인 또는 [네트워킹 프로바이더](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법) 문서를 참조한다. ## 네트워크 플러그인 요구 사항 -파드 네트워킹을 구성하고 정리하기 위해 [`NetworkPlugin` 인터페이스](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go)를 제공하는 것 외에도, 플러그인은 kube-proxy에 대한 특정 지원이 필요할 수 있다. iptables 프록시는 분명히 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. 예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. 플러그인이 리눅스 브리지를 사용하지 않는 경우(그러나 Open vSwitch나 다른 메커니즘과 같은 기능을 사용함) 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다. +쿠버네티스를 빌드하거나 배포하는 플러그인 개발자와 사용자들을 위해, 플러그인은 kube-proxy를 지원하기 위한 특정 설정이 필요할 수도 있다. +iptables 프록시는 iptables에 의존하며, 플러그인은 컨테이너 트래픽이 iptables에 사용 가능하도록 해야 한다. +예를 들어, 플러그인이 컨테이너를 리눅스 브릿지에 연결하는 경우, 플러그인은 `net/bridge/bridge-nf-call-iptables` sysctl을 `1` 로 설정하여 iptables 프록시가 올바르게 작동하는지 확인해야 한다. +플러그인이 Linux 브리지를 사용하지 않고 대신 Open vSwitch나 다른 메커니즘을 사용하는 경우, 컨테이너 트래픽이 프록시에 대해 적절하게 라우팅되도록 해야 한다. kubelet 네트워크 플러그인이 지정되지 않은 경우, 기본적으로 `noop` 플러그인이 사용되며, `net/bridge/bridge-nf-call-iptables=1` 을 설정하여 간단한 구성(브릿지가 있는 도커 등)이 iptables 프록시에서 올바르게 작동하도록 한다. -### CNI +### 루프백 CNI -CNI 플러그인은 Kubelet에 `--network-plugin=cni` 커맨드라인 옵션을 전달하여 선택된다. Kubelet은 `--cni-conf-dir`(기본값은 `/etc/cni/net.d`)에서 파일을 읽고 해당 파일의 CNI 구성을 사용하여 각 파드의 네트워크를 설정한다. CNI 구성 파일은 [CNI 명세](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration)와 일치해야 하며, 구성에서 참조하는 필수 CNI 플러그인은 `--cni-bin-dir`(기본값은 `/opt/cni/bin`)에 있어야 한다. +쿠버네티스 네트워크 모델을 구현하기 위해 노드에 설치된 CNI 플러그인 외에도, 쿠버네티스는 각 샌드박스(파드 샌드박스, VM 샌드박스 등)에 사용되는 루프백 인터페이스 `lo`를 제공하기 위한 컨테이너 런타임도 요구한다. +루프백 인터페이스 구현은 [CNI 루프백 플러그인](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)을 재사용하거나 자체 코드를 개발하여 수행할 수 있다. ([CRI-O 예시 참조](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)) -디렉터리에 여러 CNI 구성 파일이 있는 경우, kubelet은 이름별 알파벳 순으로 구성 파일을 사용한다. - -구성 파일에 지정된 CNI 플러그인 외에도, 쿠버네티스는 최소 0.2.0 버전의 표준 CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) 플러그인이 필요하다. - -#### hostPort 지원 +### hostPort 지원 CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 팀이 제공하는 공식 [포트맵(portmap)](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) 플러그인을 사용하거나 portMapping 기능이 있는 자체 플러그인을 사용할 수 있다. @@ -80,7 +93,7 @@ CNI 네트워킹 플러그인은 `hostPort` 를 지원한다. CNI 플러그인 } ``` -#### 트래픽 셰이핑 지원 +### 트래픽 셰이핑(shaping) 지원 **실험적인 기능입니다** @@ -132,8 +145,4 @@ metadata: ... ``` -## 용법 요약 - -* `--network-plugin=cni` 는 `--cni-bin-dir`(기본값 `/opt/cni/bin`)에 있는 실제 CNI 플러그인 바이너리와 `--cni-conf-dir`(기본값 `/etc/cni/net.d`)에 있는 CNI 플러그인 구성과 함께 `cni` 네트워크 플러그인을 사용하도록 지정한다. - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 0403a1f1b8..67bde697ba 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -111,7 +111,9 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 {{% thirdparty-content %}} * [Charmed Operator Framework](https://juju.is/) +* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk) * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) +* [kube-rs](https://kube.rs/) (Rust) * [kubebuilder](https://book.kubebuilder.io/) 사용하기 * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET 오퍼레이터 SDK) * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 0281daaae0..8c2ab31c68 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -76,7 +76,7 @@ card: 쿠버네티스는 주로 클러스터 내부 통신을 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한 -자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 디자인 제안과 +자세한 내용은 [쿠버네티스 Protobuf 직렬화](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) 디자인 제안과 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한 IDL(인터페이스 정의 언어) 파일을 참고한다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 69afaa0069..b2af3e1f1a 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -100,4 +100,4 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다. ## {{% heading "whatsnext" %}} * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기. -* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기. +* [쿠버네티스의 식별자와 이름](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) 디자인 문서 읽기. From 38983125e3df883c12cfc835f8d29f751bb034d0 Mon Sep 17 00:00:00 2001 From: Kyungjin Kim Date: Sun, 24 Jul 2022 12:00:35 +0900 Subject: [PATCH 021/202] [ko] Translate docs/en/tasks/administer-cluster/namespaces into Korean --- .../tasks/administer-cluster/namespaces.md | 319 ++++++++++++++++++ 1 file changed, 319 insertions(+) create mode 100644 content/ko/docs/tasks/administer-cluster/namespaces.md diff --git a/content/ko/docs/tasks/administer-cluster/namespaces.md b/content/ko/docs/tasks/administer-cluster/namespaces.md new file mode 100644 index 0000000000..ebcc640447 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/namespaces.md @@ -0,0 +1,319 @@ +--- + + + +title: 네임스페이스를 사용해 클러스터 공유하기 +content_type: task +--- + + +이 페이지는 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}를 살펴보고, 작업하고, 삭제하는 방법에 대해 다룬다. 또한 쿠버네티스 네임스페이스를 사용해 클러스터를 세분화하는 방법에 대해서도 다룬다. + + +## {{% heading "prerequisites" %}} + +* [기존 쿠버네티스 클러스터](/ko/docs/setup/)가 있다. +* 쿠버네티스 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip term_id="service" text="서비스" >}}, 그리고 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}에 대해 이해하고 있다. + + + + +## 네임스페이스 보기 + +1. 아래 명령어를 사용해 클러스터의 현재 네임스페이스를 나열한다. + +```shell +kubectl get namespaces +``` +``` +NAME STATUS AGE +default Active 11d +kube-system Active 11d +kube-public Active 11d +``` + +쿠버네티스를 시작하면 세 개의 초기 네임스페이스가 있다. + + * `default` 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스 + * `kube-system` 쿠버네티스 시스템에서 생성된 오브젝트의 네임스페이스 + * `kube-public` 이 네임스페이스는 자동으로 생성되며 모든 사용자(미인증 사용자를 포함)가 읽을 수 있다. 이 네임스페이스는 일부 리소스를 공개적으로 보고 읽을 수 있어야 하는 경우에 대비하여 대부분이 클러스터 사용을 위해 예약돼 있다. 그러나 이 네임스페이스의 공개적인 성격은 관례일 뿐 요구 사항은 아니다. + +아래 명령을 실행해 특정 네임스페이스에 대한 요약 정보를 볼 수 있다. + +```shell +kubectl get namespaces +``` + +자세한 정보를 보는 것도 가능하다. + +```shell +kubectl describe namespaces +``` +``` +Name: default +Labels: +Annotations: +Status: Active + +No resource quota. + +Resource Limits + Type Resource Min Max Default + ---- -------- --- --- --- + Container cpu - - 100m +``` + +이러한 세부 정보에는 리소스 한도(limit) 범위 뿐만 아니라 리소스 쿼터(만약 있다면)까지 모두 표시된다. + +리소스 쿼터는 *네임스페이스* 내 리소스의 집계 사용량을 추적하며, +*네임스페이스*에서 사용할 수 있는 *하드(Hard)* 리소스 사용 제한을 클러스터 운영자가 정의할 수 있도록 해준다. + +제한 범위는 하나의 엔티티(entity)가 하나의 *네임스페이스*에서 사용할 수 있는 +리소스 양에 대한 최대/최소 제약 조건을 정의한다. + +[어드미션 컨트롤: 리밋 레인지(Limit Range)](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조하자. + +네임스페이스는 다음 두 상태 중 하나에 있을 수 있다. + + * `Active` 네임스페이스가 사용 중이다. + * `Terminating` 네임스페이스가 삭제 중이므로 새 오브젝트에 사용할 수 없다. + +자세한 내용은 API 레퍼런스의 [네임스페이스](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/)를 +참조한다. + +## 새 네임스페이스 생성하기 + +{{< note >}} + `kube-` 접두사는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 이를 사용해 네임스페이스를 생성하지 않도록 한다. +{{< /note >}} + +1. `my-namespace.yaml`이라는 YAML 파일을 생성하고 아래 내용을 작성한다. + + ```yaml + apiVersion: v1 + kind: Namespace + metadata: + name: + ``` + 다음 명령을 실행한다. + + ``` + kubectl create -f ./my-namespace.yaml + ``` + +2. 아래 명령으로 네임스페이스를 생성할 수도 있다. + + ``` + kubectl create namespace + ``` + +네임스페이스의 이름은 +유효한 [DNS 레이블](/docs/concepts/overview/working-with-objects/names#dns-label-names)이어야 한다. + +옵션 필드인 `finalizer`는 네임스페이스가 삭제 될 때 관찰자가 리소스를 제거할 수 있도록 한다. 존재하지 않는 파이널라이저(finalizer)를 명시한 경우 네임스페이스는 생성되지만 사용자가 삭제하려 하면 `Terminating` 상태가 된다. + +파이널라이저에 대한 자세한 내용은 네임스페이스 [디자인 문서](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md#finalizers)에서 확인할 수 있다. + +## 네임스페이스 삭제하기 + +다음 명령을 실행해 네임스페이스를 삭제한다. + +```shell +kubectl delete namespaces +``` + +{{< warning >}} +이렇게 하면 네임스페이스의 _모든 것_ 이 삭제된다! +{{< /warning >}} + +삭제는 비동기적이므로 삭제 후 한동안은 네임스페이스의 상태가 `Terminating`으로 보일 것이다. + +## 쿠버네티스 네임스페이스를 사용해 클러스터 세분화하기 + +1. 기본 네임스페이스 이해하기 + + 기본적으로 쿠버네티스 클러스터는 클러스터에서 사용할 기본 파드, 서비스, 그리고 디플로이먼트(Deployment) 집합을 가지도록 + 클러스터를 프로비저닝 할 때 기본 네임스페이스를 인스턴스화한다. + + 새 클러스터가 있다고 가정하고 아래 명령을 수행하면 사용 가능한 네임스페이스를 볼 수 있다. + + ```shell + kubectl get namespaces + ``` + ``` + NAME STATUS AGE + default Active 13m + ``` + +2. 새 네임스페이스 생성하기 + + 이 예제에서는 내용을 저장할 쿠버네티스 네임스페이스를 추가로 두 개 생성할 것이다. + + 개발과 프로덕션 유스케이스에서 공유 쿠버네티스 클러스터를 사용하는 조직이 있다고 가정하자. + + 개발 팀은 애플리케이션을 구축하고 실행하는데 사용하는 파드, 서비스, 디플로이먼트의 목록을 볼 수 있는 공간을 클러스터에 유지하려 한다. + 이 공간에서는 쿠버네티스 리소스가 자유롭게 추가 및 제거되고, + 누가 리소스를 수정할 수 있는지 없는지에 대한 제약이 완화돼 빠른 개발이 가능해진다. + + 운영 팀은 운영 사이트를 실행하는 파드, 서비스, 디플로이먼트 집합을 조작할 수 있는 사람과 + 그렇지 않은 사람들에 대해 엄격한 절차를 적용할 수 있는 공간을 클러스터에 유지하려 한다. + + 이 조직이 따를 수 있는 한 가지 패턴은 쿠버네티스 클러스터를 `development(개발)`와 `production(운영)`이라는 두 개의 네임스페이스로 분할하는 것이다. + + 우리의 작업을 보존하기 위해 새로운 네임스페이스 두 개를 만들자. + + kubectl을 사용해 `development` 네임스페이스를 생성한다. + + ```shell + kubectl create -f https://k8s.io/examples/admin/namespace-dev.json + ``` + + 그런 다음 kubectl을 사용해 `production` 네임스페이스를 생성한다. + + ```shell + kubectl create -f https://k8s.io/examples/admin/namespace-prod.json + ``` + + 제대로 생성이 되었는지 확인하기 위해 클러스터 내의 모든 네임스페이스를 나열한다. + + ```shell + kubectl get namespaces --show-labels + ``` + ``` + NAME STATUS AGE LABELS + default Active 32m + development Active 29s name=development + production Active 23s name=production + ``` + +3. 네임스페이스마다 파드 생성 + + 쿠버네티스 네임스페이스는 클러스터의 파드, 서비스 그리고 디플로이먼트의 범위를 제공한다. + + 하나의 네임스페이스와 상호 작용하는 사용자는 다른 네임스페이스의 내용을 볼 수 없다. + + 이를 보여주기 위해 `development` 네임스페이스에서 간단히 디플로이먼트와 파드를 생성하자. + + ```shell + kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development --replicas=2 + ``` + 호스트 이름을 제공하는 기본 컨테이너로 `snowflake`라는 이름의 파드를 실행하는 레플리카 사이즈 2의 디플로이먼트를 생성했다. + + ```shell + kubectl get deployment -n=development + ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + snowflake 2/2 2 2 2m + ``` + ```shell + kubectl get pods -l app=snowflake -n=development + ``` + ``` + NAME READY STATUS RESTARTS AGE + snowflake-3968820950-9dgr8 1/1 Running 0 2m + snowflake-3968820950-vgc4n 1/1 Running 0 2m + ``` + + 개발자들은 `production` 네임스페이스의 내용에 영향을 끼칠 걱정 없이 하고 싶은 것을 할 수 있으니 대단하지 않은가. + + 이제 `production` 네임스페이스로 전환해 한 네임스페이스의 리소스가 다른 네임스페이스에서는 어떻게 숨겨지는지 보자. + + `production` 네임스페이스는 비어있어야 하며 아래 명령은 아무 것도 반환하지 않아야 한다. + + ```shell + kubectl get deployment -n=production + kubectl get pods -n=production + ``` + + 프로덕션은 마치 가축을 키우는 것과 같다. 그래서 우리도 cattle(가축)이라는 이름의 파드들을 생성하도록 하겠다. + + ```shell + kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production + kubectl scale deployment cattle --replicas=5 -n=production + + kubectl get deployment -n=production + ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + cattle 5/5 5 5 10s + ``` + + ```shell + kubectl get pods -l app=cattle -n=production + ``` + ``` + NAME READY STATUS RESTARTS AGE + cattle-2263376956-41xy6 1/1 Running 0 34s + cattle-2263376956-kw466 1/1 Running 0 34s + cattle-2263376956-n4v97 1/1 Running 0 34s + cattle-2263376956-p5p3i 1/1 Running 0 34s + cattle-2263376956-sxpth 1/1 Running 0 34s + ``` + +지금 쯤이면 사용자가 한 네임스페이스에 생성한 리소스는 다른 네임스페이스에서 숨겨져 있어야 한다는 것을 잘 알고 있을 것이다. + +쿠버네티스 정책 지원이 발전함에 따라, 이 시나리오를 확장해 각 네임스페이스에 +서로 다른 인증 규칙을 제공하는 방법을 보이도록 하겠다. + + + + + +## 네임스페이스의 사용 동기 이해하기 + +단일 클러스터는 여러 사용자 및 사용자 그룹(이하 '사용자 커뮤니티')의 요구를 충족시킬 수 있어야 한다. + +쿠버네티스 _네임스페이스_ 는 여러 프로젝트, 팀 또는 고객이 쿠버네티스 클러스터를 공유할 수 있도록 지원한다. + +이를 위해 다음을 제공한다. + +1. [이름](/ko/docs/concepts/overview/working-with-objects/names/)에 대한 범위 +2. 인증과 정책을 클러스터의 하위 섹션에 연결하는 메커니즘 + +여러 개의 네임스페이스를 사용하는 것은 선택 사항이다. + +각 사용자 커뮤니티는 다른 커뮤니티와 격리된 상태로 작업할 수 있기를 원한다. + +각 사용자 커뮤니티는 다음을 가진다. + +1. 리소스 (파드, 서비스, 레플리케이션 컨트롤러(replication controller) 등 +2. 정책 (커뮤니티에서 조치를 수행할 수 있거나 없는 사람) +3. 제약 조건 (해당 커뮤니티에서는 어느 정도의 쿼터가 허용되는지 등) + +클러스터 운영자는 각 사용자 커뮤니티 마다 네임스페이스를 생성할 수 있다. + +네임스페이스는 다음을 위한 고유한 범위를 제공한다. + +1. (기본 명명 충돌을 방지하기 위해) 명명된 리소스 +2. 신뢰할 수 있는 사용자에게 관리 권한 위임 +3. 커뮤니티 리소스 소비를 제한하는 기능 + +유스케이스는 다음을 포함한다. + +1. 클러스터 운영자로서 단일 클러스터에서 여러 사용자 커뮤니티를 지원하려 한다. +2. 클러스터 운영자로서 클러스터 분할에 대한 권한을 + 해당 커뮤니티의 신뢰할 수 있는 사용자에게 위임하려 한다. +3. 클러스터 운영자로서 클러스터를 사용하는 다른 커뮤니티에 미치는 영향을 제한하기 위해 + 각 커뮤니티가 사용할 수 있는 리소스의 양을 제한하고자 한다. +4. 클러스터 사용자로서 다른 사용자 커뮤니티가 클러스터에서 수행하는 작업과는 별도로 + 사용자 커뮤니티와 관련된 리소스와 상호 작용하고 싶다. + +## 네임스페이스와 DNS 이해하기 + +[서비스](/ko/docs/concepts/services-networking/service/)를 생성하면 상응하는 [DNS 엔트리(entry)](/ko/docs/concepts/services-networking/dns-pod-service/)가 생성된다. +이 엔트리는 `<서비스-이름><네임스페이스=이름>.svc.cluster.local` 형식을 갖는데, +컨테이너가 `<서비스-이름>`만 갖는 경우에는 네임스페이스에 국한된 서비스로 연결된다. +이 기능은 개발, 스테이징 및 프로덕션과 같이 +여러 네임스페이스 내에서 동일한 설정을 사용할 때 유용하다. +네임스페이스를 넘어서 접근하려면 전체 주소 도메인 이름(FQDN)을 사용해야 한다. + + + +## {{% heading "whatsnext" %}} + +* [네임스페이스 선호(preference)](/ko/docs/concepts/overview/working-with-objects/namespaces/#선호하는-네임스페이스-설정하기)에 대해 자세히 알아보기. +* [요청(request)에 대한 네임스페이스 설정](/ko/docs/concepts/overview/working-with-objects/namespaces/#요청에-네임스페이스-설정하기)에 대해 자세히 알아보기. +* [네임스페이스 설계](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md) 참조하기. + + From 5514e78418fab67232866b3287d205893f22c93d Mon Sep 17 00:00:00 2001 From: Georg Pirklbauer Date: Wed, 27 Jul 2022 09:02:43 +0200 Subject: [PATCH 022/202] Fix typo in german docs --- content/de/docs/concepts/containers/images.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/de/docs/concepts/containers/images.md b/content/de/docs/concepts/containers/images.md index 68bc356bc0..e6a0beb166 100644 --- a/content/de/docs/concepts/containers/images.md +++ b/content/de/docs/concepts/containers/images.md @@ -5,7 +5,7 @@ weight: 10 --- -Sie erstellen ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann. +Sie erstellen Ihr Docker Image und laden es in eine Registry hoch, bevor es in einem Kubernetes Pod referenziert werden kann. Die `image` Eigenschaft eines Containers unterstüzt die gleiche Syntax wie die des `docker` Kommandos, inklusive privater Registries und Tags. @@ -75,7 +75,7 @@ Authentifizierungsdaten können auf verschiedene Weisen hinterlegt werden: - Alle Pods können jedes gecachte Image auf einem Node nutzen - Setzt root - Zugriff auf allen Nodes zum Einrichten voraus - Spezifizieren eines ImagePullSecrets auf einem Pod - - Nur Pods, die eigene Secret tragen, haben Zugriff auf eine private Registry + - Nur Pods, die eigene Secrets tragen, haben Zugriff auf eine private Registry Jede Option wird im Folgenden im Detail beschrieben @@ -246,7 +246,7 @@ Falls jedoch die `imagePullPolicy` Eigenschaft der Containers auf `IfNotPresent` Wenn Sie sich auf im Voraus heruntergeladene Images als Ersatz für eine Registry - Authentifizierung verlassen möchten, müssen sie sicherstellen, dass alle Knoten die gleichen, im Voraus heruntergeladenen Images aufweisen. -Diese Medthode kann dazu genutzt werden, bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen. +Diese Methode kann dazu genutzt werden, bestimmte Images aus Geschwindigkeitsgründen im Voraus zu laden, oder als Alternative zur Authentifizierung an einer eigenen Registry zu nutzen. Alle Pods haben Leserechte auf alle im Voraus geladenen Images. From c5bc5ab9aae0706e969cdb832bb77ae26d13cd11 Mon Sep 17 00:00:00 2001 From: mocha-123 Date: Wed, 27 Jul 2022 23:36:40 +0900 Subject: [PATCH 023/202] [ko] Translate the glossary term 'Cluster Infrastructure' into Korean --- .../reference/glossary/cluster-infrastructure.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 content/ko/docs/reference/glossary/cluster-infrastructure.md diff --git a/content/ko/docs/reference/glossary/cluster-infrastructure.md b/content/ko/docs/reference/glossary/cluster-infrastructure.md new file mode 100644 index 0000000000..6641bf4020 --- /dev/null +++ b/content/ko/docs/reference/glossary/cluster-infrastructure.md @@ -0,0 +1,13 @@ +--- +title: 클러스터 인프라스트럭처(Cluster Infrastructure) +id: cluster-infrastructure +date: 2019-05-12 +full_link: +short_description: > + 인프라스트럭처 계층은 VM, 네트워킹, 보안 그룹 등을 제공하고 유지한다. + +aka: +tags: +- operation +--- + 인프라스트럭처 계층은 VM, 네트워킹, 보안 그룹 등을 제공하고 유지한다. From b1a1f8e766c8a0de3d8eb90c2ca305ec710ca62e Mon Sep 17 00:00:00 2001 From: mocha-123 Date: Thu, 28 Jul 2022 12:22:10 +0900 Subject: [PATCH 024/202] [ko] fix typo infrastructure --- content/ko/docs/concepts/architecture/cloud-controller.md | 4 ++-- content/ko/docs/concepts/storage/storage-classes.md | 2 +- content/ko/docs/reference/glossary/istio.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index eccfe091ce..e8988cad16 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -8,8 +8,8 @@ weight: 40 {{< feature-state state="beta" for_k8s_version="v1.11" >}} -클라우드 인프라스트럭쳐 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다. -쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭쳐를 +클라우드 인프라스트럭처 기술을 통해 퍼블릭, 프라이빗 그리고 하이브리드 클라우드에서 쿠버네티스를 실행할 수 있다. +쿠버네티스는 컴포넌트간의 긴밀한 결합 없이 자동화된 API 기반의 인프라스트럭처를 신뢰한다. {{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="클라우드 컨트롤러 매니저는">}} diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 970b7f3ddd..b527e9a2b5 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -534,7 +534,7 @@ vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티 * 쿠버네티스 내부의 가상 SAN 정책 지원 - Vsphere 인프라스트럭쳐(Vsphere Infrastructure (VI)) 관리자는 + Vsphere 인프라스트럭처(Vsphere Infrastructure (VI)) 관리자는 동적 볼륨 프로비저닝 중에 사용자 정의 가상 SAN 스토리지 기능을 지정할 수 있다. 이제 동적 볼륨 프로비저닝 중에 스토리지 기능의 형태로 성능 및 가용성과 같은 스토리지 요구 사항을 정의할 diff --git a/content/ko/docs/reference/glossary/istio.md b/content/ko/docs/reference/glossary/istio.md index 1734ebdc7f..86f0ac9b3b 100644 --- a/content/ko/docs/reference/glossary/istio.md +++ b/content/ko/docs/reference/glossary/istio.md @@ -16,5 +16,5 @@ tags: -Istio를 추가하는 것은 애플리케이션 코드 변경을 요구하지 않는다. 그것은 서비스와 네트워크 사이의 인프라스트럭쳐 레이어이다. 이는 서비스 디플로이먼트와 조합되었을 때, 일반적으로 서비스 메시라고 일컫는다. Istio의 컨트롤 플레인은 쿠버네티스, Mesosphere 등과 같은 하부의 클러스터 관리 플랫폼을 추상화한다. +Istio를 추가하는 것은 애플리케이션 코드 변경을 요구하지 않는다. 그것은 서비스와 네트워크 사이의 인프라스트럭처 레이어이다. 이는 서비스 디플로이먼트와 조합되었을 때, 일반적으로 서비스 메시라고 일컫는다. Istio의 컨트롤 플레인은 쿠버네티스, Mesosphere 등과 같은 하부의 클러스터 관리 플랫폼을 추상화한다. From 3f2126172737a1c46d7569a626c83a093be5d942 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Sat, 23 Jul 2022 20:02:13 +0900 Subject: [PATCH 025/202] [ko] Translate the glossary term 'Ephemeral Container' into Korean --- .../reference/glossary/ephemeral-container.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 content/ko/docs/reference/glossary/ephemeral-container.md diff --git a/content/ko/docs/reference/glossary/ephemeral-container.md b/content/ko/docs/reference/glossary/ephemeral-container.md new file mode 100644 index 0000000000..b2ee6c9939 --- /dev/null +++ b/content/ko/docs/reference/glossary/ephemeral-container.md @@ -0,0 +1,20 @@ +--- +title: 임시 컨테이너(Ephemeral Container) +id: ephemeral-container +date: 2019-08-26 +full_link: /ko/docs/concepts/workloads/pods/ephemeral-containers/ +short_description: > + 파드 내에 임시적으로 실행할 수 있는 컨테이너 타입 + +aka: +tags: +- fundamental +--- +{{< glossary_tooltip text="파드" term_id="pod" >}} 내에 임시적으로 실행할 수 있는 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 타입. + + + +문제가 있는 실행 중 파드를 조사하고 싶다면, 파드에 임시 컨테이너를 추가하고 진단을 수행할 수 있다. 임시 컨테이너는 리소스 및 스케줄링에 대한 보장이 제공되지 않으며, 워크로드 자체를 실행하기 위해 임시 컨테이너를 사용해서는 안 된다. + + +더 자세한 정보는 파드 API의 [EphemeralContainer](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#EphemeralContainer)를 참고한다. From b16960a8e2339debe41334162f53fb67f1f87a81 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Sun, 24 Jul 2022 14:02:40 +0900 Subject: [PATCH 026/202] [ko] Translate the glossary term 'Pod Priority' --- .../ko/docs/reference/glossary/pod-priority.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/ko/docs/reference/glossary/pod-priority.md diff --git a/content/ko/docs/reference/glossary/pod-priority.md b/content/ko/docs/reference/glossary/pod-priority.md new file mode 100644 index 0000000000..8d6d807887 --- /dev/null +++ b/content/ko/docs/reference/glossary/pod-priority.md @@ -0,0 +1,17 @@ +--- +title: 파드 프라이어리티(Pod Priority) +id: pod-priority +date: 2019-01-31 +full_link: /ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위 +short_description: > + 파드 프라이어리티는 다른 파드에 대한 상대적인 중요도를 나타낸다. + +aka: +tags: +- operation +--- + 파드 프라이어리티는 다른 {{< glossary_tooltip text="파드" term_id="pod" >}}에 대한 상대적인 중요도를 나타낸다. + + + +[파드 프라이어리티](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위)는 특정 파드에 다른 파드와 비교하여 높거나 낮은 스케줄링 우선 순위를 설정할 수 있도록 해 주며, 이는 프로덕션 클러스터 워크로드에 있어서 중요한 기능이다. From 6fb28754d412e588a754870f69a708e3c623d0e5 Mon Sep 17 00:00:00 2001 From: Rishit Dagli Date: Tue, 26 Jul 2022 05:47:24 +0000 Subject: [PATCH 027/202] Add the accepted types for `imagePullSecrets` --- content/en/docs/concepts/containers/images.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index c07880a458..cb0911bd03 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -275,6 +275,8 @@ in private registries. {{< /note >}} Kubernetes supports specifying container image registry keys on a Pod. +`imagePullSecrets` must all be in the same namespace as the Pod. The referenced +Secrets must be of type `kubernetes.io/dockercfg` or `kubernetes.io/dockerconfigjson`. #### Creating a Secret with a Docker config @@ -303,7 +305,8 @@ so this process needs to be done one time per namespace. #### Referring to an imagePullSecrets on a Pod Now, you can create pods which reference that secret by adding an `imagePullSecrets` -section to a Pod definition. +section to a Pod definition. Each item in the `imagePullSecrets` array can only +reference a Secret in the same namespace. For example: From 4f7d6ab342c76a4e34cbc588d64e1b9e0b129c02 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Thu, 21 Jul 2022 16:36:15 +0900 Subject: [PATCH 028/202] [ko] Update outdated files in dev-1.24-ko.2 (M54-M64) --- content/ko/docs/reference/_index.md | 9 +- .../reference/access-authn-authz/_index.md | 2 + .../feature-gates.md | 6 +- .../kube-proxy.md | 156 ++++++---- .../reference/glossary/managed-service.md | 4 - .../reference/glossary/service-catalog.md | 6 +- .../ko/docs/reference/kubectl/cheatsheet.md | 21 +- .../labels-annotations-taints/_index.md | 271 +++++++++++++++++- content/ko/docs/reference/using-api/_index.md | 8 +- .../reference/using-api/client-libraries.md | 19 +- 10 files changed, 412 insertions(+), 90 deletions(-) diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 0f1f0d7155..1b472a3451 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -77,9 +77,11 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 * [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/) +* [kube-apiserver 요청 제한 (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/) * [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/) +* [kubelet 자격증명 제공자 (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) +* [kubelet 자격증명 제공자 (v1beta1)](/docs/reference/config-api/kubelet-credentialprovider.v1beta1/) * [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/) @@ -87,6 +89,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 * [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및 [클라이언트 인증 API (v1)](/docs/reference/config-api/client-authentication.v1/) * [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [이미지 정책 API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/) ## kubeadm을 위한 API 설정 @@ -96,5 +99,5 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 ## 설계 문서 쿠버네티스 기능에 대한 설계 문서의 아카이브. -[쿠버네티스 아키텍처](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)와 -[쿠버네티스 디자인 개요](https://git.k8s.io/community/contributors/design-proposals)가 좋은 출발점이다. +[쿠버네티스 아키텍처](https://git.k8s.io/design-proposals-archive/architecture/architecture.md)와 +[쿠버네티스 디자인 개요](https://git.k8s.io/design-proposals-archive)부터 읽어보는 것이 좋다. diff --git a/content/ko/docs/reference/access-authn-authz/_index.md b/content/ko/docs/reference/access-authn-authz/_index.md index 0c910199b7..ff6c38bc32 100644 --- a/content/ko/docs/reference/access-authn-authz/_index.md +++ b/content/ko/docs/reference/access-authn-authz/_index.md @@ -24,3 +24,5 @@ no_list: true - 서비스 어카운트 - [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/) - [관리](/ko/docs/reference/access-authn-authz/service-accounts-admin/) +- [kubelet 인증과 인가](/docs/reference/access-authn-authz/kubelet-authn-authz/) + - kubelet [TLS 부트스트래핑](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)을 포함함 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 c1746978b2..8d06536a7d 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 @@ -760,7 +760,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다. 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) +- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 마운트할 수 있다. - `CSIServiceAccountToken` : 볼륨을 마운트하는 파드의 서비스 계정 토큰을 받을 수 있도록 @@ -1087,10 +1087,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 참조한다. - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. 자세한 내용은 - [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. + [kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. 자세한 사항은 - [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다. + [kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다. - `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다. - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md index 70753d44a4..ecf66c0757 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -43,10 +43,17 @@ kube-proxy [flags] ---azure-container-registry-config string +--add_dir_header -

Azure 컨테이너 레지스트리 구성 정보가 들어 있는 파일의 경로.

+

true인 경우 파일 경로를 로그 메시지의 헤더에 추가한다.

+ + + +--alsologtostderr + + +

파일과 함께, 표준 에러에도 로그를 출력한다.

@@ -70,13 +77,6 @@ kube-proxy [flags]

boot-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.

- ---boot_id_file string     기본값: "/proc/sys/kernel/random/boot_id" - - -

boot-id를 체크할 파일들의 콤마로 구분된 목록. 목록 중에서, 존재하는 첫 번째 파일을 사용한다.

- - --cleanup @@ -84,25 +84,11 @@ kube-proxy [flags]

true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다.

- ---cloud-provider-gce-l7lb-src-cidrs cidrs     기본값: 130.211.0.0/22,35.191.0.0/16 - - -

GCE 방화벽에서, L7 로드밸런싱 트래픽 프록시와 헬스 체크를 위해 개방할 CIDR 목록

- - - ---cloud-provider-gce-lb-src-cidrs cidrs     기본값: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16 - - -

GCE 방화벽에서, L4 로드밸런싱 트래픽 프록시와 헬스 체크를 위해 개방할 CIDR 목록

- - --cluster-cidr string -

클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다

+

클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다. 듀얼-스택(dual-stack) 클러스터의 경우, 각 IP 체계(IPv4와 IPv6)별로 최소한 하나의 CIDR을 포함하는 목록(쉼표로 분리)을 가진다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

@@ -147,39 +133,25 @@ kube-proxy [flags]

설정된 TCP 연결에 대한 유휴시간 초과(값이 0이면 그대로 유지)

- ---default-not-ready-toleration-seconds int     기본값: 300 - - -

notReady:NoExecute 상태에 대한 톨러레이션(toleration) 시간이 지정되지 않은 모든 파드에 기본값으로 지정될 톨러레이션 시간(단위: 초)

- - - ---default-unreachable-toleration-seconds int     기본값: 300 - - -

unreachable:NoExecute 상태에 대한 톨러레이션 시간이 지정되지 않은 모든 파드에 기본값으로 지정될 톨러레이션 시간(단위: 초)

- - --detect-local-mode LocalMode -

로컬 트래픽을 탐지하는 데 사용할 모드

+

로컬 트래픽을 탐지하는 데 사용할 모드. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

---feature-gates mapStringBool +--feature-gates <쉼표로 구분된 'key=True|False' 쌍들> -

A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=true)
CSIMigrationAzureDisk=true|false (BETA - default=true)
CSIMigrationAzureFile=true|false (BETA - default=false)
CSIMigrationGCE=true|false (BETA - default=true)
CSIMigrationOpenStack=true|false (BETA - default=true)
CSIMigrationPortworx=true|false (ALPHA - default=false)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIStorageCapacity=true|false (BETA - default=true)
CSIVolumeHealth=true|false (ALPHA - default=false)
CSRDuration=true|false (BETA - default=true)
ControllerManagerLeaderMigration=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceValidationExpressions=true|false (ALPHA - default=false)
DaemonSetUpdateSurge=true|false (BETA - default=true)
DefaultPodTopologySpread=true|false (BETA - default=true)
DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
DownwardAPIHugePages=true|false (BETA - default=true)
EfficientWatchResumption=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (BETA - default=true)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GRPCContainerProbe=true|false (ALPHA - default=false)
GracefulNodeShutdown=true|false (BETA - default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (ALPHA - default=false)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HonorPVReclaimPolicy=true|false (ALPHA - default=false)
IdentifyPodOS=true|false (ALPHA - default=false)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
InTreePluginRBDUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
IndexedJob=true|false (BETA - default=true)
JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
JobReadyPods=true|false (ALPHA - default=false)
JobTrackingWithFinalizers=true|false (BETA - default=true)
KubeletCredentialProviders=true|false (ALPHA - default=false)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (ALPHA - default=false)
NetworkPolicyEndPort=true|false (BETA - default=true)
NodeSwap=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
OpenAPIEnums=true|false (ALPHA - default=false)
OpenAPIV3=true|false (ALPHA - default=false)
PodAffinityNamespaceSelector=true|false (BETA - default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
PodSecurity=true|false (BETA - default=true)
PreferNominatedNode=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
SeccompDefault=true|false (ALPHA - default=false)
ServerSideFieldValidation=true|false (ALPHA - default=false)
ServiceInternalTrafficPolicy=true|false (BETA - default=true)
ServiceLBNodePortControl=true|false (BETA - default=true)
ServiceLoadBalancerClass=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
StatefulSetMinReadySeconds=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
SuspendJob=true|false (BETA - default=true)
TopologyAwareHints=true|false (BETA - default=false)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (BETA - default=true)
csiMigrationRBD=true|false (ALPHA - default=false)

+

알파/실험적 기능의 기능 게이트를 나타내는 `key=value` 쌍의 집합. 사용 가능한 옵션은 다음과 같다:

APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (BETA - default=true)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=true)
CSIMigrationAzureFile=true|false (BETA - default=true)
CSIMigrationGCE=true|false (BETA - default=true)
CSIMigrationPortworx=true|false (ALPHA - default=false)
CSIMigrationRBD=true|false (ALPHA - default=false)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIVolumeHealth=true|false (ALPHA - default=false)
CronJobTimeZone=true|false (ALPHA - default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceValidationExpressions=true|false (ALPHA - default=false)
DaemonSetUpdateSurge=true|false (BETA - default=true)
DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
DownwardAPIHugePages=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GRPCContainerProbe=true|false (BETA - default=true)
GracefulNodeShutdown=true|false (BETA - default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HonorPVReclaimPolicy=true|false (ALPHA - default=false)
IdentifyPodOS=true|false (BETA - default=true)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
InTreePluginRBDUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
JobReadyPods=true|false (BETA - default=true)
JobTrackingWithFinalizers=true|false (BETA - default=false)
KubeletCredentialProviders=true|false (BETA - default=true)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (BETA - default=true)
NetworkPolicyEndPort=true|false (BETA - default=true)
NetworkPolicyStatus=true|false (ALPHA - default=false)
NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
NodeSwap=true|false (ALPHA - default=false)
OpenAPIEnums=true|false (BETA - default=true)
OpenAPIV3=true|false (BETA - default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodSecurity=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
SeccompDefault=true|false (ALPHA - default=false)
ServerSideFieldValidation=true|false (ALPHA - default=false)
ServiceIPStaticSubrange=true|false (ALPHA - default=false)
ServiceInternalTrafficPolicy=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
StatefulSetMinReadySeconds=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
TopologyAwareHints=true|false (BETA - default=true)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (BETA - default=true)

--config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

--healthz-bind-address ipport     기본값: 0.0.0.0:10256 -

헬스 체크 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4의 인터페이스의 경우 '0.0.0.0:10256', 모든 IPv6의 인터페이스인 경우 '[::]:10256'로 설정). 사용 안 할 경우 빈칸으로 둠.

+

헬스 체크 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4의 인터페이스의 경우 '0.0.0.0:10256', 모든 IPv6의 인터페이스인 경우 '[::]:10256'로 설정)이며, 사용 안 할 경우 빈칸으로 둔다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

@@ -302,14 +274,42 @@ kube-proxy [flags] ---machine-id-file string     기본값: "/etc/machine-id,/var/lib/dbus/machine-id" +--log_backtrace_at <'file:N' 형식의 문자열>     기본값: :0 -

machine-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.

+

파일의 N개 줄만큼 로그를 남기게 되면, 스택 트레이스를 출력한다.

---machine_id_file string     기본값: "/etc/machine-id,/var/lib/dbus/machine-id" +--log_dir string + + +

로그 파일을 지정된 경로 아래에 쓰며, 비어있을 경우 무시된다.

+ + + +--log_file string + + +

지정된 로그 파일을 사용하며, 비어있을 경우 무시된다.

+ + + +--log_file_max_size uint     기본값: 1800 + + +

로그 파일의 최대 크기를 MB 단위로 지정하며, 값이 0일 경우는 최대 크기에 제한이 없다.

+ + + +--logtostderr     기본값: true + + +

로그를 파일 대신 표준 에러에 출력한다.

+ + + +--machine-id-file string     기본값: "/etc/machine-id,/var/lib/dbus/machine-id"

machine-id를 위해 확인할 파일 목록(쉼표로 분리). 가장 먼저 발견되는 항목을 사용한다.

@@ -333,7 +333,7 @@ kube-proxy [flags] --metrics-bind-address ipport     기본값: 127.0.0.1:10249 -

메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨). 사용하지 않으려면 비워둘 것.

+

메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨)로, 사용하지 않으려면 비워둔다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

@@ -343,25 +343,46 @@ kube-proxy [flags]

NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.

+ +--one_output + + +

true일 경우, 심각도 기본 레벨에서만 로그를 쓴다(false일 경우 크게 심각하지 않은 단계에서도 로그를 쓴다).

+ + --oom-score-adj int32     기본값: -999 -

kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다.

+

kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

+ + + +--pod-bridge-interface string + + +

클러스터 내의 브리지 인터페이스 이름으로, kube-proxy는 지정된 인터페이스로부터 발생한 트래픽을 로컬로 간주한다. DetectLocalMode가 BridgeInterface로 설정되어 있을 경우, 해당 인자도 같이 설정되어야 한다.

+ + + +--pod-interface-name-prefix string + + +

클러스터 내에서 인터페이스의 접두사로, kube-proxy는 지정된 접두사가 붙은 인터페이스로부터 발생한 트래픽을 로컬로 간주한다. DetectLocalMode가 InterfaceNamePrefix로 설정되어 있을 경우, 해당 인자도 같이 설정되어야 한다.

--profiling -

값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다.

+

값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

--proxy-mode ProxyMode -

사용할 프록시 모드: 'userspace' (이전) or 'iptables' (빠름) or 'ipvs' or 'kernelspace' (윈도우). 공백인 경우 가장 잘 사용할 수 있는 프록시(현재는 iptables)를 사용한다. iptables 프록시를 선택했지만, 시스템의 커널 또는 iptables 버전이 맞지 않으면, 항상 userspace 프록시로 변경된다.

+

사용할 프록시 모드: 'iptables' (리눅스), 'ipvs' (리눅스), 'kernelspace' (윈도우), or 'userspace' (리눅스/윈도우, 지원 중단). 리눅스에서의 기본값은 'iptables'이며, 윈도우에서의 기본값은 'userspace'이다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

@@ -375,7 +396,28 @@ kube-proxy [flags] --show-hidden-metrics-for-version string -

숨겨진 메트릭을 표시하려는 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. 포멧은 <메이저>.<마이너> 와 같으며, 예를 들면 '1.16' 과 같다. 이 포멧의 목적은, 다음 릴리스가 숨길 추가적인 메트릭을 사용자에게 공지하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다.

+

숨겨진 메트릭을 표시하려는 이전 버전. 이전 마이너 버전만 인식하며, 다른 값은 허용하지 않는다. 포멧은 <메이저>.<마이너> 와 같으며, 예를 들면 '1.16' 과 같다. 이 포멧의 목적은, 다음 릴리스가 숨길 추가적인 메트릭을 사용자에게 공지하여, 그 이후 릴리스에서 메트릭이 영구적으로 삭제됐을 때 사용자가 놀라지 않도록 하기 위함이다. --config를 통해 설정 파일이 명시될 경우 이 파라미터는 무시된다.

+ + + +--skip_headers + + +

true일 경우, 로그 메시지에 헤더를 쓰지 않는다.

+ + + +--skip_log_headers + + +

true일 경우, 로그 파일을 열 때 헤더를 보여주지 않는다.

+ + + +--stderrthreshold int     기본값: 2 + + +

해당 임계값 이상의 로그를 표준에러로 보낸다.

@@ -385,6 +427,13 @@ kube-proxy [flags]

유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.

+ +-v, --v int + + +

로그 상세 레벨(verbosity) 값

+ + --version version[=true] @@ -392,6 +441,13 @@ kube-proxy [flags]

버전 정보를 출력하고 종료

+ +--vmodule <쉼표로 구분된 'pattern=N' 설정들> + + +

파일 필터 로깅을 위한 pattern=N 설정 목록(쉼표로 분리).

+ + --write-config-to string diff --git a/content/ko/docs/reference/glossary/managed-service.md b/content/ko/docs/reference/glossary/managed-service.md index 7ecf8aa1d8..9fdb523623 100644 --- a/content/ko/docs/reference/glossary/managed-service.md +++ b/content/ko/docs/reference/glossary/managed-service.md @@ -7,7 +7,6 @@ short_description: > 타사 공급자가 유지보수하는 소프트웨어. aka: - tags: - extension --- @@ -17,6 +16,3 @@ tags: 매니지드 서비스의 몇 가지 예시로 AWS EC2, Azure SQL Database 그리고 GCP Pub/Sub이 있으나, 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품이 될 수 있다. -[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는 -{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}가 제공하는 -매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다. diff --git a/content/ko/docs/reference/glossary/service-catalog.md b/content/ko/docs/reference/glossary/service-catalog.md index 25f1667853..9866accdc4 100644 --- a/content/ko/docs/reference/glossary/service-catalog.md +++ b/content/ko/docs/reference/glossary/service-catalog.md @@ -4,15 +4,15 @@ id: service-catalog date: 2018-04-12 full_link: short_description: > - 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다. + 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이, 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록 해주던 이전의 확장 API이다. aka: tags: - extension --- - 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록하는 확장 API이다. + 쿠버네티스 클러스터 내에서 실행되는 응용 프로그램이, 클라우드 공급자가 제공하는 데이터 저장소 서비스와 같은 외부 관리 소프트웨어 제품을 쉽게 사용할 수 있도록 해주던 이전의 확장 API이다. -서비스 생성 또는 관리에 대한 자세한 지식 없이도 {{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}를 통해 외부의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}의 목록과 프로비전, 바인딩하는 방법을 제공한다. +서비스 생성 또는 관리에 대한 자세한 지식 없이도 외부의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}의 목록과 프로비전, 바인딩하는 방법을 제공한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 051c4502ed..3aed766d8a 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -30,14 +30,14 @@ echo "source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash ```bash alias k=kubectl -complete -F __start_kubectl k +complete -o default -F __start_kubectl k ``` ### ZSH ```bash source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정 -echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다. +echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다. ``` ### --all-namespaces 에 대한 노트 @@ -265,22 +265,22 @@ kubectl autoscale deployment foo --min=2 --max=10 # 디플로이 ## 리소스 패치 ```bash -kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 노드를 부분적으로 업데이트 +# 노드를 부분적으로 업데이트 +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' -# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요. +# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요 kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' -# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트. +# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트 kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' -# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화. +# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화 kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' # 위치 배열에 새 요소 추가 kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' -# Update a deployment's replicas count by patching it's scale subresource -# 디플로이먼트의 scale 서브리소스를 패치하여 레플리카 카운트를 업데이트. +# 디플로이먼트의 scale 서브리소스를 패치하여 레플리카 수 업데이트 kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}' ``` @@ -381,7 +381,10 @@ kubectl cluster-info # 마스 kubectl cluster-info dump # 현재 클러스터 상태를 stdout으로 덤프 kubectl cluster-info dump --output-directory=/path/to/cluster-state # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프 -# key와 effect가 있는 테인트(taint)가 이미 존재하면, 그 값이 지정된 대로 대체된다. +# 현재 노드에 존재하고 있는 테인트(taint)들을 확인 +kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect + +# 이미 존재하고 있는 key와 effect를 갖는 테인트의 경우, 지정한 값으로 대체 kubectl taint nodes foo dedicated=special-user:NoSchedule ``` diff --git a/content/ko/docs/reference/labels-annotations-taints/_index.md b/content/ko/docs/reference/labels-annotations-taints/_index.md index 5c098a0084..9aa175ef2a 100644 --- a/content/ko/docs/reference/labels-annotations-taints/_index.md +++ b/content/ko/docs/reference/labels-annotations-taints/_index.md @@ -2,6 +2,7 @@ title: 잘 알려진 레이블, 어노테이션, 테인트(Taint) content_type: concept weight: 20 + --- @@ -10,10 +11,80 @@ weight: 20 이 문서는 각 값에 대한 레퍼런스를 제공하며, 값을 할당하기 위한 협력 포인트도 제공한다. - - +## API 오브젝트에서 사용되는 레이블, 어노테이션, 테인트 + +### app.kubernetes.io/component + +예시: `app.kubernetes.io/component: "database"` + +적용 대상: 모든 오브젝트 + +아키텍처 내의 컴포넌트. + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + +### app.kubernetes.io/created-by + +예시: `app.kubernetes.io/created-by: "controller-manager"` + +적용 대상: 모든 오브젝트 + +리소스를 생성한 컨트롤러/사용자. + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + +### app.kubernetes.io/instance + +예시: `app.kubernetes.io/instance: "mysql-abcxzy"` + +적용 대상: 모든 오브젝트 + +애플리케이션 인스턴스를 식별하기 위한 고유한 이름. + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + +### app.kubernetes.io/managed-by + +예시: `app.kubernetes.io/managed-by: "helm"` + +적용 대상: 모든 오브젝트 + +애플리케이션의 작업을 관리하기 위해 사용되는 도구. + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + +### app.kubernetes.io/name + +예시: `app.kubernetes.io/name: "mysql"` + +적용 대상: 모든 오브젝트 + +애플리케이션의 이름. + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + +### app.kubernetes.io/part-of + +예시: `app.kubernetes.io/part-of: "wordpress"` + +적용 대상: 모든 오브젝트 + +해당 애플리케이션이 속한 상위 레벨의 애플리케이션 이름. + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + +### app.kubernetes.io/version + +예시: `app.kubernetes.io/version: "5.7.21"` + +적용 대상: 모든 오브젝트 + +애플리케이션의 현재 버전(시맨틱 버전, 리비전 해시, 기타 등등). + +[추천하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/#labels)을 확인한다. + ## kubernetes.io/arch 예시: `kubernetes.io/arch=amd64` @@ -72,15 +143,69 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k 어떤 오브젝트를 변경할 수도 있는 `kubectl` 명령에 `--record` 플래그를 사용하면 이 레이블이 추가된다. +### kubernetes.io/description {#description} + +예시: `kubernetes.io/description: "Description of K8s object."` + +적용 대상: 모든 오브젝트 + +이 어노테이션은 주어진 오브젝트의 특정 상태를 표현하는데 사용한다. + +### kubernetes.io/enforce-mountable-secrets {#enforce-mountable-secrets} + +예시: `kubernetes.io/enforce-mountable-secrets: "true"` + +적용 대상: 서비스어카운트(ServiceAccount) + +이 어노테이션의 값은 **true**로 설정되어야만 작동한다. 이 어노테이션은, 해당 서비스어카운트로 동작중인 파드가 그 서비스어카운트의 `secrets` 항목에 명시된 Secret API 오브젝트만을 참조한다는 뜻이다. + ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} 예시: `controller.kubernetes.io/pod-deletion-cost=10` -적용 대상: Pod +적용 대상: 파드 이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을 설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다. +### kubernetes.io/ingress-bandwidth + +{{< note >}} +인그레스 트래픽 조절 어노테이션은 실험적인 기능이다. +만약 트래픽 조절 기능을 활성화시키고 싶다면, CNI 설정 파일(기본적으로 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 추가해야 하며, +실행파일이 CNI의 실행파일 경로(기본적으로 `/opt/cni/bin`) 아래에 포함되어있는지도 확인하자. +{{< /note >}} + +Example: `kubernetes.io/ingress-bandwidth: 10M` + +적용 대상: 파드 + +파드에 QoS(quality-of-service)를 적용함으로써 가용한 대역폭을 효과적으로 제한할 수 있다. +인그레스 트래픽(파드로 향하는)은 효과적으로 데이터를 처리하기 위해 대기 중인 패킷을 큐로 관리한다. +파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고 +`kubernetes.io/ingress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 인그레스 속도를 명시할 때 사용되는 단위는 +초당 비트([수량](/docs/reference/kubernetes-api/common-definitions/quantity/))이다. +예를 들어, `10M`은 초당 10 메가비트를 의미한다. + +### kubernetes.io/egress-bandwidth + +{{< note >}} +이그레스 트래픽 조절 어노테이션은 실험적인 기능이다. +만약 트래픽 조절 기능을 활성화시키고 싶다면, CNI 설정 파일(기본적으로 `/etc/cni/net.d`)에 `bandwidth` 플러그인을 추가해야 하며, +실행파일이 CNI의 실행파일 경로(기본적으로 `/opt/cni/bin`) 아래에 포함되어있는지도 확인하자. +{{< /note >}} + +예시: `kubernetes.io/egress-bandwidth: 10M` + +적용 대상: 파드 + +이그레스 트래픽(파드로부터의)은 설정된 속도를 초과하는 패킷을 삭제하는 정책에 의해 처리되며, +파드에 거는 제한은 다른 파드의 대역폭에 영향을 주지 않는다. +파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고 +`kubernetes.io/egress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 이그레스 속도를 명시할 때 사용되는 단위는 +초당 비트([수량](/docs/reference/kubernetes-api/common-definitions/quantity/))이다. +예를 들어, `10M`은 초당 10 메가비트를 의미한다. + ## beta.kubernetes.io/instance-type (사용 중단됨) {{< note >}} v1.17부터, [`node.kubernetes.io/instance-type`](#nodekubernetesioinstance-type)으로 대체되었다. {{< /note >}} @@ -163,13 +288,23 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클 예시: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath` -적용 대상: PersistentVolumeClaim +적용 대상: 퍼시스턴트볼륨클레임(PersistentVolumeClaim) + +이 어노테이션은 사용 중단되었다. + +### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options} + +예시 : `volume.beta.kubernetes.io/mount-options: "ro,soft"` + +적용 대상: 퍼시스턴트볼륨 + +쿠버네티스 관리자는, 노드에 퍼시스턴트볼륨이 마운트될 경우 추가적인 [마운트 옵션](/ko/docs/concepts/storage/persistent-volumes/#mount-options)을 명세할 수 있다. 이 어노테이션은 사용 중단되었다. ## volume.kubernetes.io/storage-provisioner -적용 대상: PersistentVolumeClaim +적용 대상: 퍼시스턴트볼륨클레임 이 어노테이션은 동적 프로비저닝이 요구되는 PVC에 추가될 예정이다. @@ -199,6 +334,24 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo 쿠버네티스가 여러 서비스를 구분하기 위해 이 레이블을 사용한다. 현재는 `ELB`(Elastic Load Balancer) 를 위해서만 사용되고 있다. +### kubernetes.io/service-account.name + +예시: `kubernetes.io/service-account.name: "sa-name"` + +Used on: 시크릿(Secret) + +이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 +서비스어카운트의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다. + +### kubernetes.io/service-account.uid + +예시: `kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da` + +적용 대상: 시크릿 + +이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는 +서비스어카운트의 {{< glossary_tooltip term_id="uid" text="고유 ID">}}를 기록한다. + ## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} 예시: `endpointslice.kubernetes.io/managed-by="controller"` @@ -257,7 +410,7 @@ v1.18부터, `spec.ingressClassName`으로 대체되었다. 적용 대상: 스토리지클래스(StorageClass) 하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우, -클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 리소스는 해당 기본 클래스로 할당될 것이다. +클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임 리소스는 해당 기본 클래스로 할당될 것이다. ## alpha.kubernetes.io/provided-node-ip @@ -354,6 +507,21 @@ kubelet은 노드의 `imagefs.available`, `imagefs.inodesFree`, `nodefs.availabl kubelet은 '`/proc/sys/kernel/pid_max`의 크기의 D-값'과 노드에서 쿠버네티스가 사용 중인 PID를 확인하여, `pid.available` 지표라고 불리는 '사용 가능한 PID 수'를 가져온다. 그 뒤, 관측한 지표를 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다. +### node.kubernetes.io/out-of-service + +예시: `node.kubernetes.io/out-of-service:NoExecute` + +사용자는 노드에 테인트를 수동으로 추가함으로써 서비스 중이 아니라고 표시할 수 있다. 만약 `NodeOutOfServiceVolumeDetach` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 `kube-controller-manager`에 활성화되어 있으며 +노드가 이 테인트로 인해 서비스 중이 아니라고 표시되어있을 경우, 노드에서 실행되던 매칭되는 톨러레이션이 없는 파드들은 강제로 삭제됨과 동시에 볼륨이 분리된다. 이는 서비스 중이 아닌 노드의 파드들이 다른 노드에서 빠르게 복구될 수 있도록 해준다. + +{{< caution >}} +이 테인트를 언제 어떻게 사용할지에 대한 자세한 사항은 +[논 그레이스풀 노드 셧다운](/ko/docs/concepts/architecture/nodes/#non-graceful-node-shutdown) +를 참조한다. +{{< /caution >}} + + ## node.cloudprovider.kubernetes.io/uninitialized 예시: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule` @@ -465,3 +633,94 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다. 튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며, 이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다. + +### snapshot.storage.kubernetes.io/allowVolumeModeChange + +예시: `snapshot.storage.kubernetes.io/allowVolumeModeChange: "true"` + +적용 대상: VolumeSnapshotContent + +값은 `true` 혹은 `false`만을 받는다. +{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}이 +볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우, +사용자가 소스 볼륨의 모드를 수정할 수 있는지 여부를 결정한다. + +자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) +와 [쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. + +## Audit을 위한 어노테이션들 + + +- [`authorization.k8s.io/decision`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-decision) +- [`authorization.k8s.io/reason`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-reason) +- [`insecure-sha1.invalid-cert.kubernetes.io/$hostname`](/docs/reference/labels-annotations-taints/audit-annotations/#insecure-sha1-invalid-cert-kubernetes-io-hostname) +- [`missing-san.invalid-cert.kubernetes.io/$hostname`](/docs/reference/labels-annotations-taints/audit-annotations/#missing-san-invalid-cert-kubernetes-io-hostname) +- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations) +- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy) +- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt) + +자세한 사항은 [Audit 어노테이션](/docs/reference/labels-annotations-taints/audit-annotations/) 페이지를 참고한다. + +## kubeadm + +### kubeadm.alpha.kubernetes.io/cri-socket + +예시: `kubeadm.alpha.kubernetes.io/cri-socket: unix:///run/containerd/container.sock` + +적용 대상: 노드 + +kubeadm `init`/`join`시 주어지는 CRI 소켓 정보를 유지하기 위해 사용하는 어노테이션. +kubeadm은 노드 오브젝트를 이 정보를 주석 처리한다. 이상적으로는 KubeletConfiguration의 항목이어야 하기 때문에, +어노테이션은 "alpha" 상태로 남아있다. + +### kubeadm.kubernetes.io/etcd.advertise-client-urls + +예시: `kubeadm.kubernetes.io/etcd.advertise-client-urls: https://172.17.0.18:2379` + +적용 대상: 파드 + +etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위해, 로컬에서 관리되는 etcd 파드에 배치되는 어노테이션. +주로 etcd 클러스터의 헬스 체크에 사용한다. + +### kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint + +예시: `kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: https//172.17.0.18:6443` + +적용 대상: 파드 + +외부로 노출시킬 API 서버의 엔드포인트를 추적하기 위해, +로컬에서 관리되는 kube-apiserver 파드에 배치되는 어노테이션. + +### kubeadm.kubernetes.io/component-config.hash + +예시: `kubeadm.kubernetes.io/component-config.hash: 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae` + +적용 대상: 컨피그맵(ConfigMap) + +컴포넌트 설정을 관리하는 컨피그맵에 배치되는 어노테이션. +사용자가 특정 컴포넌트에 대해서 kubeadm 기본값과 다른 설정값을 적용했는지 판단하기 위한 해시(SHA-256)를 가지고 있다. + +### node-role.kubernetes.io/control-plane + +적용 대상: 노드 + +kubeadm이 관리하는 컨트롤 플레인 노드에 적용되는 레이블. + +### node-role.kubernetes.io/control-plane + +예시: `node-role.kubernetes.io/control-plane:NoSchedule` + +적용 대상: 노드 + +중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트. + +### node-role.kubernetes.io/master + +예시: `node-role.kubernetes.io/master:NoSchedule` + +적용 대상: 노드 + +중요한 워크로드만 스케줄링할 수 있도록 컨트롤 플레인 노드에 적용시키는 테인트. + +{{< note >}} 버전 v1.20 부터, 이 테인트는 `node-role.kubernetes.io/control-plane`의 등장으로 더 이상 사용되지 않으며, +버전 v1.25에서 삭제될 예정이다.{{< /note >}} diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 28e7dace35..39e0acc172 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -39,7 +39,7 @@ JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. -[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 +[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/design-proposals-archive/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. @@ -83,8 +83,8 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. ## API 그룹 -[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 -쿠버네티스 API를 더 쉽게 확장하게 해준다. +[API 그룹](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md)은 +쿠버네티스 API를 더 쉽게 확장할 수 있도록 해 준다. API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에 명시된다. @@ -123,5 +123,5 @@ API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에 ## {{% heading "whatsnext" %}} - [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기 -- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에 +- [애그리게이터(aggregator)](https://git.k8s.io/design-proposals-archive/api-machinery/aggregated-api-servers.md)에 대한 디자인 문서 읽기 diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 25edc311b2..781372baf4 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -28,14 +28,17 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. [쿠버네티스 SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery)에서 공식적으로 관리된다. -| 언어 | 클라이언트 라이브러리 | 예제 프로그램 | -|----------|----------------|-----------------| -| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) -| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) -| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) -| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) -| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) -| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) +| 언어 | 클라이언트 라이브러리 | 예제 프로그램 | +|------------|----------------|-----------------| +| C | [github.com/kubernetes-client/c](https://github.com/kubernetes-client/c/) | [둘러보기](https://github.com/kubernetes-client/c/tree/master/examples) +| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) +| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) +| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) +| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Perl | [github.com/kubernetes-client/perl/](https://github.com/kubernetes-client/perl/) | [둘러보기](https://github.com/kubernetes-client/perl/tree/master/examples) +| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) +| Ruby | [github.com/kubernetes-client/ruby/](https://github.com/kubernetes-client/ruby/) | [둘러보기](https://github.com/kubernetes-client/ruby/tree/master/examples) ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리 From d92788889d440158df26abf814bbe57df97bc26a Mon Sep 17 00:00:00 2001 From: shine09 Date: Fri, 29 Jul 2022 14:26:55 +0900 Subject: [PATCH 029/202] Translate unlocalized text 35491 --- content/ko/docs/contribute/new-content/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/ko/docs/contribute/new-content/_index.md b/content/ko/docs/contribute/new-content/_index.md index 9020b80f1f..ab9c85c5ed 100644 --- a/content/ko/docs/contribute/new-content/_index.md +++ b/content/ko/docs/contribute/new-content/_index.md @@ -43,10 +43,10 @@ class S,T spacewhite class first,second white {{}} -***Figure - Contributing new content preparation*** +***그림 - 새로운 콘텐츠 기여를 위한 준비*** -The figure above depicts the information you should know -prior to submitting new content. The information details follow. +위 그림은 새로운 콘텐츠를 제출하기 전에 알아야 할 정보를 설명한다. +해당 정보에 대한 자세한 내용은 다음과 같다. From 345209a12e2de579a37555962d0bb5ea04f27103 Mon Sep 17 00:00:00 2001 From: onestone9900 Date: Fri, 29 Jul 2022 19:54:42 +0900 Subject: [PATCH 030/202] modify: access-cluster-services - 104.197.5.247 to 192.0.2.1 --- .../access-cluster-services.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster-services.md b/content/ko/docs/tasks/access-application-cluster/access-cluster-services.md index ab083d3690..a63db14fe2 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster-services.md @@ -64,16 +64,16 @@ kubectl cluster-info 출력은 다음과 비슷하다. ``` -Kubernetes master is running at https://104.197.5.247 -elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy -kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy -kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy -grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +Kubernetes master is running at https://192.0.2.1 +elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy +kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy +kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy +grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy ``` 각 서비스에 접근하기 위한 프록시-작업 URL이 표시된다. -예를 들어, 이 클러스터에는 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 로 +예를 들어, 이 클러스터에는 `https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 로 접근할 수 있는 (Elasticsearch를 사용한) 클러스터 수준 로깅이 활성화되어 있다. 적합한 자격 증명이 전달되는 경우나 kubectl proxy를 통해 도달할 수 있다. 예를 들어 다음의 URL에서 확인할 수 있다. `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`. @@ -103,13 +103,13 @@ URL에서 `<서비스_이름>`이 지원하는 형식은 다음과 같다. * Elasticsearch 서비스 엔드포인트 `_search?q=user:kimchy` 에 접근하려면, 다음을 사용한다. ``` - http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy + http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy ``` * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다. ``` - https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true + https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true ``` 상태 정보는 다음과 비슷하다. @@ -132,7 +132,7 @@ URL에서 `<서비스_이름>`이 지원하는 형식은 다음과 같다. * *https* Elasticsearch 서비스 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다. ``` - https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true + https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true ``` #### 웹 브라우저를 사용하여 클러스터에서 실행되는 서비스에 접근 From 89f2bc1801cc89e71bc490210637625de4cbf52a Mon Sep 17 00:00:00 2001 From: onestone9900 Date: Fri, 29 Jul 2022 20:03:08 +0900 Subject: [PATCH 031/202] =?UTF-8?q?modify:=20#=EB=B9=8C=ED=8A=B8=EC=9D=B8-?= =?UTF-8?q?=EC=84=9C=EB=B9=84=EC=8A=A4-=EA=B2=80=EC=83=89=20to=20/ko/.../a?= =?UTF-8?q?ssess-cluster-services/#discovering-builtin-services/#=EB=B9=8C?= =?UTF-8?q?=ED=8A=B8=EC=9D=B8-=EC=84=9C=EB=B9=84=EC=8A=A4-=EA=B2=80?= =?UTF-8?q?=EC=83=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../ko/docs/tasks/access-application-cluster/access-cluster.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index ab884150aa..ad5bf250a5 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -233,7 +233,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록 - apiserver를 위치지정한다 - 인증 header들을 추가한다 -1. [apiserver proxy](#빌트인-서비스-검색): +1. [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster-services/#빌트인-서비스-검색): - apiserver 내의 빌트인 bastion이다 - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP로 연결한다 From 66249b4464d32a6cd0ce6bfd2fcd1d3ea0eda907 Mon Sep 17 00:00:00 2001 From: onestone9900 Date: Fri, 29 Jul 2022 20:29:38 +0900 Subject: [PATCH 032/202] modify: shell script --- .../configure-access-multiple-clusters.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index b3997580f2..d42fd1d96e 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -271,7 +271,7 @@ contexts: ### 리눅스 ```shell -export KUBECONFIG_SAVED=$KUBECONFIG +export KUBECONFIG_SAVED="$KUBECONFIG" ``` ### 윈도우 PowerShell @@ -290,7 +290,7 @@ $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ### 리눅스 ```shell -export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 +export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2" ``` ### 윈도우 PowerShell @@ -356,7 +356,7 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 ### 리눅스 ```shell -export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config +export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config" ``` ### 윈도우 Powershell @@ -379,7 +379,7 @@ kubectl config view ### 리눅스 ```shell -export KUBECONFIG=$KUBECONFIG_SAVED +export KUBECONFIG="$KUBECONFIG_SAVED" ``` ### 윈도우 PowerShell From 3fd8eb48eb0179b473c62779e6c7545137a02d85 Mon Sep 17 00:00:00 2001 From: onestone9900 Date: Fri, 29 Jul 2022 20:39:12 +0900 Subject: [PATCH 033/202] modify: indent 4 -> 3 --- ...port-forward-access-application-cluster.md | 223 +++++++++--------- 1 file changed, 105 insertions(+), 118 deletions(-) diff --git a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index 6aa257dca4..1dcccf6bd1 100644 --- a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -11,180 +11,170 @@ min-kubernetes-server-version: v1.10 실행중인 MongoDB 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스 디버깅에 유용할 수 있다. - - - ## {{% heading "prerequisites" %}} - * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * [MongoDB Shell](https://www.mongodb.com/try/download/shell)을 설치한다. - - - ## MongoDB 디플로이먼트와 서비스 생성하기 1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml + ``` - 성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다. + 성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다. - ``` - deployment.apps/mongo created - ``` + ``` + deployment.apps/mongo created + ``` - 파드 상태를 조회하여 파드가 준비되었는지 확인한다. + 파드 상태를 조회하여 파드가 준비되었는지 확인한다. - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - 출력은 파드가 생성되었다는 것을 보여준다. + 출력은 파드가 생성되었다는 것을 보여준다. - ``` - NAME READY STATUS RESTARTS AGE - mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s - ``` + ``` + NAME READY STATUS RESTARTS AGE + mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s + ``` - 디플로이먼트 상태를 조회한다. + 디플로이먼트 상태를 조회한다. - ```shell - kubectl get deployment - ``` + ```shell + kubectl get deployment + ``` - 출력은 디플로이먼트가 생성되었다는 것을 보여준다. + 출력은 디플로이먼트가 생성되었다는 것을 보여준다. - ``` - NAME READY UP-TO-DATE AVAILABLE AGE - mongo 1/1 1 1 2m21s - ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + mongo 1/1 1 1 2m21s + ``` - 디플로이먼트는 자동으로 레플리카셋을 관리한다. - 아래의 명령어를 사용하여 레플리카셋 상태를 조회한다. + 디플로이먼트는 자동으로 레플리카셋을 관리한다. + 아래의 명령어를 사용하여 레플리카셋 상태를 조회한다. - ```shell - kubectl get replicaset - ``` + ```shell + kubectl get replicaset + ``` - 출력은 레플리카셋이 생성되었다는 것을 보여준다. - - ``` - NAME DESIRED CURRENT READY AGE - mongo-75f59d57f4 1 1 1 3m12s - ``` + 출력은 레플리카셋이 생성되었다는 것을 보여준다. + ``` + NAME DESIRED CURRENT READY AGE + mongo-75f59d57f4 1 1 1 3m12s + ``` 2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml + ``` - 성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다. + 성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다. - ``` - service/mongo created - ``` + ``` + service/mongo created + ``` - 서비스가 생성되었는지 확인한다. + 서비스가 생성되었는지 확인한다. - ```shell + ```shell kubectl get service mongo - ``` + ``` - 출력은 서비스가 생성되었다는 것을 보여준다. + 출력은 서비스가 생성되었다는 것을 보여준다. - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - mongo ClusterIP 10.96.41.183 27017/TCP 11s - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + mongo ClusterIP 10.96.41.183 27017/TCP 11s + ``` 3. MongoDB 서버가 파드 안에서 실행되고 있고, 27017번 포트에서 수신하고 있는지 확인한다. - ```shell - # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. - kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' - ``` + ```shell + # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. + kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' + ``` - 출력은 파드 내 MongoDB 포트 번호를 보여준다. + 출력은 파드 내 MongoDB 포트 번호를 보여준다. - ``` - 27017 - ``` + ``` + 27017 + ``` - (이는 인터넷 상의 MongoDB에 할당된 TCP 포트이다.) + (27017은 인터넷 상의 MongoDB에 할당된 TCP 포트이다.) ## 파드의 포트를 로컬 포트로 포워딩하기 -1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다. +1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다. - ```shell - # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. - kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 + ```shell + # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. + kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 + ``` + + 이것은 + + ```shell + kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017 + ``` + + 또는 + + ```shell + kubectl port-forward deployment/mongo 28015:27017 + ``` + + 또는 + + ```shell + kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017 + ``` + + 또는 다음과 같다. + + ```shell + kubectl port-forward service/mongo 28015:27017 ``` - 이것은 + 위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다. - ```shell - kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017 - ``` - - 또는 - - ```shell - kubectl port-forward deployment/mongo 28015:27017 - ``` - - 또는 - - ```shell - kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017 - ``` - - 또는 다음과 같다. - - ```shell - kubectl port-forward service/mongo 28015:27017 - ``` - - 위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다. - - ``` - Forwarding from 127.0.0.1:28015 -> 27017 - Forwarding from [::1]:28015 -> 27017 - ``` + ``` + Forwarding from 127.0.0.1:28015 -> 27017 + Forwarding from [::1]:28015 -> 27017 + ``` {{< note >}} - `kubectl port-forward` 는 프롬프트를 리턴하지 않으므로, 이 연습을 계속하려면 다른 터미널을 열어야 한다. - {{< /note >}} -2. MongoDB 커맨드라인 인터페이스를 실행한다. +2. MongoDB 커맨드라인 인터페이스를 실행한다. - ```shell - mongosh --port 28015 - ``` + ```shell + mongosh --port 28015 + ``` -3. MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다. +3. MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다. - ``` - db.runCommand( { ping: 1 } ) - ``` + ``` + db.runCommand( { ping: 1 } ) + ``` - 성공적인 핑 요청을 반환한다. + 성공적인 핑 요청을 반환한다. - ``` - { ok: 1 } - ``` + ``` + { ok: 1 } + ``` ### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port} @@ -204,7 +194,6 @@ Forwarding from 127.0.0.1:63753 -> 27017 Forwarding from [::1]:63753 -> 27017 ``` - ## 토의 @@ -219,9 +208,7 @@ UDP 프로토콜에 대한 지원은 [이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)에서 추적되고 있다. {{< /note >}} - - - ## {{% heading "whatsnext" %}} [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)에 대해 더 알아본다. + From 3907be01cb8282f83adabc1fcbd8177127613662 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Fri, 29 Jul 2022 13:50:22 +0900 Subject: [PATCH 034/202] Update gitignore to include some content directories --- .gitignore | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.gitignore b/.gitignore index a1bead7d25..98c74bfff7 100644 --- a/.gitignore +++ b/.gitignore @@ -27,14 +27,14 @@ kubernetes.github.io.iml nohup.out # Hugo output -public/ -resources/ +/public/ +/resources/ .hugo_build.lock # Netlify Functions build output package-lock.json -functions/ -node_modules/ +/functions/ +/node_modules/ # Generated files when building with make container-build .config/ From 720000e38aa6b53d16b31db29055c323348f3005 Mon Sep 17 00:00:00 2001 From: Yoon Date: Sat, 30 Jul 2022 01:03:09 +0900 Subject: [PATCH 035/202] [ko] Update outdated files dev-1.24-ko.2 (M51-M53) --- .../docs/contribute/review/reviewing-prs.md | 63 ++++++++++++------- .../contribute/suggesting-improvements.md | 3 +- .../ko/docs/home/supported-doc-versions.md | 7 ++- 3 files changed, 48 insertions(+), 25 deletions(-) diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index 91f8627e17..d4ba7bc37c 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -1,5 +1,5 @@ --- -title: 풀 리퀘스트 리뷰 +title: 풀 리퀘스트 리뷰하기 content_type: concept main_menu: true weight: 10 @@ -7,7 +7,8 @@ weight: 10 -누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. 쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다. +누구나 문서화에 대한 풀 리퀘스트를 리뷰할 수 있다. +쿠버네티스 website 리포지터리의 [풀 리퀘스트](https://github.com/kubernetes/website/pulls) 섹션을 방문하여 열린(open) 풀 리퀘스트를 확인한다. 문서화에 대한 풀 리퀘스트를 리뷰하는 것은 쿠버네티스 커뮤니티에 자신을 소개하는 훌륭한 방법이다. @@ -18,7 +19,7 @@ weight: 10 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. - 쿠버네티스 문서화 커뮤니티의 다양한 - [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 + [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 이해한다. @@ -27,7 +28,9 @@ weight: 10 리뷰를 시작하기 전에 다음을 명심하자. -- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고 항상 준수한다. + +- [CNCF 행동 강령](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/ko.md)을 읽고 + 항상 준수한다. - 정중하고, 사려 깊고, 도움이 되자. - PR의 긍정적인 측면과 변화에 대한 의견을 남긴다. - 당신의 리뷰를 어떻게 받아들일지에 대해 공감하고 주의한다. @@ -36,7 +39,8 @@ weight: 10 ## 리뷰 과정 -일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다. +일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 그림 1은 리뷰 과정의 단계를 보여 준다. +각 단계에 대한 상세 사항은 아래에 나와 있다. @@ -54,10 +58,10 @@ flowchart LR T[ ] -.- J[본문과 코멘트 확인]--> K[Netlify 미리보기 빌드로
변경사항 미리보기] end - + A[열려 있는 PR 목록 확인]--> B[레이블을 이용하여
PR을 필터링] B --> third --> fourth - + classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px; classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold @@ -69,32 +73,39 @@ class third,fourth white 그림 1. 리뷰 과정 절차. -1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 - 이동한다. - 쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이 - 표시된다. +1. [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로 이동한다. + 쿠버네티스 website와 문서에 대한 모든 열린 풀 리퀘스트 목록이 표시된다. 2. 다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다. - - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 참고한다. + + - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. + 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 + 참고한다. - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다. - `size/`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다. - 또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. `work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다. + 또한, PR이 진행 중인 작업으로 표시되지 않았는지 확인한다. + `work in progress` 레이블을 사용하는 PR은 아직 리뷰할 준비가 되지 않은 PR이다. 3. 리뷰할 PR을 선택한 후, 다음을 통해 변경 사항을 이해한다. + - PR 설명을 통해 변경 사항을 이해하고, 연결된 이슈 읽기 - 다른 리뷰어의 의견 읽기 - **Files changed** 탭을 클릭하여 변경된 파일과 행 보기 - - **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 Netlify 미리보기 빌드의 변경 사항을 확인. - 다음은 스크린샷이다(GitHub 데스크탑 사이트이며, + - **Conversation** 탭의 맨 아래에 있는 PR의 빌드 확인 섹션으로 스크롤하여 + Netlify 미리보기 빌드의 변경 사항을 확인. + 다음은 스크린샷이다(GitHub 데스크탑 사이트이며, 태블릿 또는 스마트폰 장치에서 리뷰하는 경우 GitHub 웹 UI가 약간 다르다). {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="Netlify 미리보기 링크를 포함하는 GitHub PR 상세 사항" >}} - 미리보기를 열려면, 체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다. + 미리보기를 열려면, + 체크 목록의 **deploy/netlify** 행의 **Details** 링크를 클릭한다. 4. **Files changed** 탭으로 이동하여 리뷰를 시작한다. + 1. 코멘트을 달려는 줄 옆에 있는 `+` 기호를 클릭한다. - 2. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다. - 3. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서 + 1. 행에 대한 의견을 작성하고 **Add single comments**(작성할 의견이 하나만 있는 경우) + 또는 **Start a review**(작성할 의견이 여러 개인 경우)를 클릭한다. + 1. 완료되면, 페이지 상단에서 **Review changes** 를 클릭한다. 여기에서 리뷰에 대한 요약을 추가하고(기여자에게 긍정적인 의견을 남겨주기 바란다!), PR을 승인하거나, 의견을 보내거나 필요에 따라 변경을 요청할 수 있다. 새로운 기여자는 항상 **Comment** 를 선택해야 한다. @@ -119,13 +130,21 @@ class third,fourth white ### 웹 사이트 -- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? +- 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? + 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? + slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? + - PR이 새로운 페이지를 소개하는가? 그렇다면, - - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가? + + - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 + 연관된 Hugo 단축 코드를 사용하는가? - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? - 페이지가 [문서 홈](/docs/home/) 목록에 나타나야 하는가? -- 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. + +- 변경 사항이 Netlify 미리보기에 표시되는가? + 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. ### 기타 -오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. 이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. +오타나 공백과 같은 작은 이슈의 PR인 경우, 코멘트 앞에 `nit:` 를 추가한다. +이를 통해 문서의 저자는 이슈가 긴급하지 않다는 것을 알 수 있다. diff --git a/content/ko/docs/contribute/suggesting-improvements.md b/content/ko/docs/contribute/suggesting-improvements.md index e10faf6ea8..d4a8856207 100644 --- a/content/ko/docs/contribute/suggesting-improvements.md +++ b/content/ko/docs/contribute/suggesting-improvements.md @@ -1,6 +1,5 @@ --- -title: 콘텐츠 개선 제안 -slug: suggest-improvements +title: 콘텐츠 개선 제안하기 content_type: concept weight: 10 card: diff --git a/content/ko/docs/home/supported-doc-versions.md b/content/ko/docs/home/supported-doc-versions.md index 35f6f9a1b0..4181a64e37 100644 --- a/content/ko/docs/home/supported-doc-versions.md +++ b/content/ko/docs/home/supported-doc-versions.md @@ -8,5 +8,10 @@ card: title: 사용 가능한 문서 버전 --- -이 웹사이트에서는 쿠버네티스 최신 버전 및 +이 웹사이트에서는 쿠버네티스 현재 버전 및 이전 4개 버전에 대한 문서를 제공하고 있다. + +쿠버네티스 버전에 따른 문서 제공 여부는 +현재 해당 릴리즈를 지원하는 것과 별개이다. +[지원 기간](/releases/patch-releases/#support-period)에서 +공식적으로 지원하는 쿠버네티스 버전과 지원 기간을 알 수 있다. \ No newline at end of file From f8e507e8dded24cf057ce0e89046bde467e6b5f8 Mon Sep 17 00:00:00 2001 From: Byung Woo LEE Date: Sat, 30 Jul 2022 01:17:12 +0900 Subject: [PATCH 036/202] Fix outdated files in dev-1.24-ko.2 (M100) (#35291) * update ko horizontal-pod-autoscale based on dev-1.24-ko.2 branch * update old urls * delete indefinite article * add whitespace to meta area --- .../horizontal-pod-autoscale.md | 226 +++++++++--------- 1 file changed, 113 insertions(+), 113 deletions(-) diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index e5c1a1ddb2..379987e800 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -14,33 +14,33 @@ weight: 90 -쿠버네티스에서, _HorizontalPodAutoscaler_ 는 워크로드 리소스(예: -{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는 -{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 자동으로 업데이트하며, +쿠버네티스에서, _HorizontalPodAutoscaler_ 는 워크로드 리소스(예: +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는 +{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 자동으로 업데이트하며, 워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 한다. -수평 스케일링은 부하 증가에 대해 -{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. -이는 _수직_ 스케일링(쿠버네티스에서는, -해당 워크로드를 위해 이미 실행 중인 파드에 +수평 스케일링은 부하 증가에 대해 +{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. +이는 _수직_ 스케일링(쿠버네티스에서는, +해당 워크로드를 위해 이미 실행 중인 파드에 더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다. -부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, -HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, +부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, +HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, 또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다. -Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예: +Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예: {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다. -HorizontalPodAutoscaler는 쿠버네티스 API 자원 및 -{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 형태로 구현되어 있다. -HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다. -쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} -내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률, -또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해 +HorizontalPodAutoscaler는 쿠버네티스 API 자원 및 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 형태로 구현되어 있다. +HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다. +쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} +내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률, +또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해 목표물(예: 디플로이먼트)의 적정 크기를 주기적으로 조정한다. -Horizontal Pod Autoscaling을 활용하는 +Horizontal Pod Autoscaling을 활용하는 [연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)가 존재한다. @@ -49,22 +49,22 @@ Horizontal Pod Autoscaling을 활용하는 {{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}} -쿠버네티스는 Horizontal Pod Autoscaling을 -간헐적으로(intermittently) 실행되는 -컨트롤 루프 형태로 구현했다(지속적인 프로세스가 아니다). -실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 +쿠버네티스는 Horizontal Pod Autoscaling을 +간헐적으로(intermittently) 실행되는 +컨트롤 루프 형태로 구현했다(지속적인 프로세스가 아니다). +실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의 `--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다). -각 주기마다, 컨트롤러 매니저는 각 HorizontalPodAutoscaler 정의에 지정된 메트릭에 대해 리소스 사용률을 질의한다. -컨트롤러 매니저는 `scaleTargetRef`에 의해 정의된 타겟 리소스를 찾고 나서, -타겟 리소스의 `.spec.selector` 레이블을 보고 파드를 선택하며, -리소스 메트릭 API(파드 단위 리소스 메트릭 용) 또는 +각 주기마다, 컨트롤러 매니저는 각 HorizontalPodAutoscaler 정의에 지정된 메트릭에 대해 리소스 사용률을 질의한다. +컨트롤러 매니저는 `scaleTargetRef`에 의해 정의된 타겟 리소스를 찾고 나서, +타겟 리소스의 `.spec.selector` 레이블을 보고 파드를 선택하며, +리소스 메트릭 API(파드 단위 리소스 메트릭 용) 또는 커스텀 메트릭 API(그 외 모든 메트릭 용)로부터 메트릭을 수집한다. * 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가 대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다. 그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의 - 컨테이너에 대한 동등한 [자원 요청](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을 + 컨테이너에 대한 동등한 [자원 요청](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을 퍼센트 단위로 하여 사용률 값을 계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다. 그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된 @@ -85,20 +85,20 @@ Horizontal Pod Autoscaling을 활용하는 버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로 선택적으로 나눌 수 있다. -HorizontalPodAutoscaler를 사용하는 일반적인 방법은 -{{< glossary_tooltip text="집약된 API" term_id="aggregation-layer" >}}(`metrics.k8s.io`, -`custom.metrics.k8s.io`, 또는 `external.metrics.k8s.io`)로부터 메트릭을 가져오도록 설정하는 것이다. -`metrics.k8s.io` API는 보통 메트릭 서버(Metrics Server)라는 애드온에 의해 제공되며, -Metrics Server는 별도로 실행해야 한다. 자원 메트릭에 대한 추가 정보는 +HorizontalPodAutoscaler를 사용하는 일반적인 방법은 +{{< glossary_tooltip text="집약된 API" term_id="aggregation-layer" >}}(`metrics.k8s.io`, +`custom.metrics.k8s.io`, 또는 `external.metrics.k8s.io`)로부터 메트릭을 가져오도록 설정하는 것이다. +`metrics.k8s.io` API는 보통 메트릭 서버(Metrics Server)라는 애드온에 의해 제공되며, +Metrics Server는 별도로 실행해야 한다. 자원 메트릭에 대한 추가 정보는 [Metrics Server](/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server)를 참고한다. -[메트릭 API를 위한 지원](#메트릭-api를-위한-지원)에서 위의 API들에 대한 안정성 보장 및 지원 상태를 +[메트릭 API를 위한 지원](#메트릭-api를-위한-지원)에서 위의 API들에 대한 안정성 보장 및 지원 상태를 확인할 수 있다. -HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하는 -워크로드 리소스(예: 디플로이먼트 및 스테이트풀셋)에 접근한다. -이들 리소스 각각은 `scale`이라는 하위 리소스를 갖고 있으며, -이 하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재 상태를 확인할 수 있도록 하는 인터페이스이다. +HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하는 +워크로드 리소스(예: 디플로이먼트 및 스테이트풀셋)에 접근한다. +이들 리소스 각각은 `scale`이라는 하위 리소스를 갖고 있으며, +이 하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재 상태를 확인할 수 있도록 하는 인터페이스이다. 쿠버네티스 API의 하위 리소스에 대한 일반적인 정보는 [쿠버네티스 API 개념](/docs/reference/using-api/api-concepts/)에서 확인할 수 있다. ### 알고리즘 세부 정보 @@ -122,11 +122,11 @@ HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하 `currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표 안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다. -허용치를 확인하고 최종 값을 결정하기 전에, -컨트롤 플레인은 누락된 메트릭이 있는지, +허용치를 확인하고 최종 값을 결정하기 전에, +컨트롤 플레인은 누락된 메트릭이 있는지, 그리고 몇 개의 파드가 [`Ready`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)인지도 고려한다. -삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면 -셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는 +삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면 +셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는 버려진다. 특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와 @@ -155,15 +155,15 @@ CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히 가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인 스케일의 크기를 약화시킨다. -또한, 아직-준비되지-않은 파드가 있고, 누락된 메트릭이나 -아직-준비되지-않은 파드가 고려되지 않고 워크로드가 스케일업 된 경우, -컨트롤러는 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고 +또한, 아직-준비되지-않은 파드가 있고, 누락된 메트릭이나 +아직-준비되지-않은 파드가 고려되지 않고 워크로드가 스케일업 된 경우, +컨트롤러는 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고 보수적으로 가정하고 스케일 확장의 크기를 약화시킨다. -아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에, -컨트롤러가 사용률을 다시 계산한다. -새로 계산한 사용률이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면, -컨트롤러가 스케일링을 건너뛴다. +아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에, +컨트롤러가 사용률을 다시 계산한다. +새로 계산한 사용률이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면, +컨트롤러가 스케일링을 건너뛴다. 그렇지 않으면, 새로 계산한 사용률를 이용하여 파드 수 변경 결정을 내린다. 평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는 @@ -188,11 +188,11 @@ HPA가 여전히 확장할 수 있음을 의미한다. ## API 오브젝트 -Horizontal Pod Autoscaler는 -쿠버네티스 `autoscaling` API 그룹의 API 리소스이다. -현재의 안정 버전은 `autoscaling/v2` API 버전이며, -메모리와 커스텀 메트릭에 대한 스케일링을 지원한다. -`autoscaling/v2`에서 추가된 새로운 필드는 `autoscaling/v1`를 이용할 때에는 +Horizontal Pod Autoscaler는 +쿠버네티스 `autoscaling` API 그룹의 API 리소스이다. +현재의 안정 버전은 `autoscaling/v2` API 버전이며, +메모리와 커스텀 메트릭에 대한 스케일링을 지원한다. +`autoscaling/v2`에서 추가된 새로운 필드는 `autoscaling/v1`를 이용할 때에는 어노테이션으로 보존된다. HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한 @@ -202,25 +202,25 @@ API 오브젝트에 대한 자세한 내용은 ## 워크로드 스케일링의 안정성 {#flapping} -HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때, -측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다. -이는 종종 *thrashing* 또는 *flapping*이라고 불린다. +HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때, +측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다. +이는 종종 *thrashing* 또는 *flapping*이라고 불린다. 이는 사이버네틱스 분야의 *이력 현상(hysteresis)* 개념과 비슷하다. ## 롤링 업데이트 중 오토스케일링 -쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다. -이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다. -디플로이먼트에 오토스케일링을 설정하려면, -각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다. -HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다. -디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여 +쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다. +이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다. +디플로이먼트에 오토스케일링을 설정하려면, +각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다. +HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다. +디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여 롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다. -오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면, -스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, +오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면, +스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, 레플리카셋과 같은 중간 리소스가 없다). ## 리소스 메트릭 지원 @@ -300,12 +300,12 @@ HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는 (이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.) -`autoscaling/v2beta2` API 버전을 사용하는 경우, -(쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은) -커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있다. +`autoscaling/v2beta2` API 버전을 사용하는 경우, +(쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은) +커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있다. 이 경우 HorizontalPodAutoscaler 컨트롤러가 이러한 커스텀 메트릭을 쿠버네티스 API로부터 조회한다. -요구 사항에 대한 정보는 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. +요구 사항에 대한 정보는 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. ## 복수의 메트릭을 이용하는 스케일링 @@ -313,10 +313,10 @@ HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는 (이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.) -`autoscaling/v2beta2` API 버전을 사용하는 경우, -HorizontalPodAutoscaler가 스케일링에 사용할 복수의 메트릭을 설정할 수 있다. -이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안한다. -HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를 +`autoscaling/v2` API 버전을 사용하는 경우, +HorizontalPodAutoscaler는 스케일링에 사용할 복수의 메트릭을 설정할 수 있다. +이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안한다. +HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를 조정한다(이 값이 이전에 설정한 '총 최대값(overall maximum)'보다는 크지 않을 때에만). ## 메트릭 API를 위한 지원 @@ -328,18 +328,18 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. * 해당 API 등록: - * 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)가 제공하는 `metrics.k8s.io` API이다. - 클러스터 애드온으로 실행할 수 있다. + * 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)가 제공하는 `metrics.k8s.io` API이다. + 클러스터 애드온으로 실행할 수 있다. - * 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다. - 사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다. + * 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다. + 사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다. - * 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다. + * 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다. 이런 다양한 메트릭 경로와 각각의 다른 점에 대한 상세 내용은 관련 디자인 제안서인 -[HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md), -[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md), -[external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md)를 참조한다. +[HPA V2](https://git.k8s.io/design-proposals-archive/autoscaling/hpa-v2.md), +[custom.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md), +[external.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/external-metrics-api.md)를 참조한다. 어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과 [외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다. @@ -350,14 +350,14 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. (이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.) -`v2` 버전의 HorizontalPodAutoscaler API를 사용한다면, -`behavior` 필드([API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec) 참고)를 +`v2` 버전의 HorizontalPodAutoscaler API를 사용한다면, +`behavior` 필드([API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec) 참고)를 사용하여 스케일업 동작과 스케일다운 동작을 별도로 구성할 수 있다. -각 방향에 대한 동작은 `behavior` 필드 아래의 +각 방향에 대한 동작은 `behavior` 필드 아래의 `scaleUp` / `scaleDown`를 설정하여 지정할 수 있다. -_안정화 윈도우_ 를 명시하여 스케일링 목적물의 -레플리카 수 [흔들림](#flapping)을 방지할 수 있다. 스케일링 정책을 이용하여 스케일링 시 +_안정화 윈도우_ 를 명시하여 스케일링 목적물의 +레플리카 수 [흔들림](#flapping)을 방지할 수 있다. 스케일링 정책을 이용하여 스케일링 시 레플리카 수 변화 속도를 조절할 수도 있다. ### 스케일링 정책 @@ -399,9 +399,9 @@ behavior: ### 안정화 윈도우 -안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 -레플리카 수의 [흔들림](#flapping)을 제한하기 위해 사용된다. -오토스케일링 알고리즘은 이전의 목표 상태를 추론하고 +안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 +레플리카 수의 [흔들림](#flapping)을 제한하기 위해 사용된다. +오토스케일링 알고리즘은 이전의 목표 상태를 추론하고 워크로드 수의 원치 않는 변화를 방지하기 위해 이 안정화 윈도우를 활용한다. 예를 들어, 다음 예제 스니펫에서, `scaleDown`에 대해 안정화 윈도우가 설정되었다. @@ -412,18 +412,18 @@ behavior: stabilizationWindowSeconds: 300 ``` -메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우, -알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다. +메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우, +알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다. 위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 된다. -이를 통해 동적 최대값(rolling maximum)을 근사화하여, +이를 통해 동적 최대값(rolling maximum)을 근사화하여, 스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지할 수 있다. ### 기본 동작 -사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야 -하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA -알고리즘의 기존 동작과 일치한다. +사용자 지정 스케일링을 사용하기 위해서 모든 필드를 지정하지 않아도 된다. 사용자 정의가 필요한 값만 +지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA +알고리즘의 기존 동작과 동일하다. ```yaml behavior: @@ -517,7 +517,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl` 실행하면 레플리카셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`, 그리고 2와 5 사이의 레플리카 개수로 설정된다. -## 암시적 유지 관리 모드 비활성화 +## 암시적 점검 모드(maintenance-mode) 비활성화 HPA 구성 자체를 변경할 필요없이 대상에 대한 HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한 @@ -529,37 +529,37 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한 ### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기 HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의 -{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서 -`spec.replicas`의 값을 삭제하는 것이 바람직하다. -이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로) -오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를 -`spec.replicas`에 기재된 값으로 조정할 것이다. +{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서 +`spec.replicas`의 값을 삭제하는 것이 바람직하다. +이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로) +오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를 +`spec.replicas`에 기재된 값으로 조정할 것이다. 이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다. -`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데, -이는 이 키의 기본값이 1이기 때문이다(레퍼런스: -[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)). -값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다. +`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데, +이는 이 키의 기본값이 1이기 때문이다(레퍼런스: +[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)). +값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다. 이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다. -이러한 1회성 저하를 방지하는 방법이 존재하며, +이러한 1회성 저하를 방지하는 방법이 존재하며, 디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다. {{< tabs name="fix_replicas_instructions" >}} {{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}} 1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>` -2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이 - 업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다. -3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다. - 소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록 - 변경 사항을 커밋하고 추가 필요 단계를 수행한다. +2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이 + 업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다. +3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다. + 소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록 + 변경 사항을 커밋하고 추가 필요 단계를 수행한다. 4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다. {{% /tab %}} {{% tab name="서버 쪽에 적용하기" %}} -[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면, -정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership) +[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면, +정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership) 가이드라인을 참조한다. {{% /tab %}} @@ -567,13 +567,13 @@ HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 ## {{% heading "whatsnext" %}} -클러스터에 오토스케일링을 구성한다면, [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)와 같은 +클러스터에 오토스케일링을 구성한다면, [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)와 같은 클러스터 수준의 오토스케일러 사용을 고려해 볼 수 있다. HorizontalPodAutoscaler에 대한 더 많은 정보는 아래를 참고한다. * horizontal pod autoscaling에 대한 [연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 확인한다. * [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 문서를 확인한다. -* 커스텀 메트릭 어댑터를 직접 작성하고 싶다면, +* 커스텀 메트릭 어댑터를 직접 작성하고 싶다면, [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다. * HorizontalPodAutoscaler [API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)를 확인한다. From 14d63129578d708bdf718e72d41fe3d799f00b8d Mon Sep 17 00:00:00 2001 From: Jinny Park Date: Sat, 30 Jul 2022 01:49:12 +0900 Subject: [PATCH 037/202] [ko] Fix outdated files in dev-1.24-ko.2 (M21-M26) (#35220) * [ko] Fix outdated files in dev-1.24-ko.2 (M21-M26) * Rev fix space typo ko/../taint-and-toleration.md Co-authored-by: Seokho Son --- .../ko/docs/concepts/policy/limit-range.md | 2 +- .../docs/concepts/policy/resource-quotas.md | 11 +- .../scheduling-eviction/assign-pod-node.md | 15 +-- .../scheduling-eviction/pod-overhead.md | 3 +- .../resource-bin-packing.md | 113 +++++++++++------- .../taint-and-toleration.md | 11 +- 6 files changed, 93 insertions(+), 62 deletions(-) diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index 8a8270be8c..a502c98c08 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -51,7 +51,7 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. ## {{% heading "whatsnext" %}} -자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)를 참조한다. +자세한 내용은 [LimitRanger 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)를 참조한다. 제한의 사용에 대한 예시는 다음을 참조한다. diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 40fe114453..cdcd0d36cb 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -1,6 +1,6 @@ --- - - +# reviewers: +# - derekwaynecarr title: 리소스 쿼터 content_type: concept weight: 20 @@ -22,8 +22,7 @@ weight: 20 리소스 쿼터는 다음과 같이 작동한다. -- 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을 - 적용하기 위한 지원이 계획되어 있다. +- 다른 팀은 다른 네임스페이스에서 작업한다. 이것은 [RBAC](/docs/reference/access-authn-authz/rbac/)으로 설정할 수 있다. - 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다. @@ -698,7 +697,7 @@ resourcequota/pods-cluster-services created ## {{% heading "whatsnext" %}} -- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다. +- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md)를 참고한다. - [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고한다. -- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 읽는다. +- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md)를 읽는다. - [제한된 자원](https://github.com/kubernetes/kubernetes/pull/36765)을 참고한다. 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 51ecff20b4..71d053708b 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -124,8 +124,8 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 이 예시에서는 다음의 규칙이 적용된다. - * 노드는 키가 `kubernetes.io/os`이고 값이 `linux`인 레이블을 - 갖고 *있어야 한다* . + * 노드는 키가 `topology.kubernetes.io/zone`인 레이블을 갖고 *있어야 하며*, + 레이블의 값이 `antarctica-east1` 혹은 `antarctica-west1`*여야 한다*. * 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을 갖고 있는 노드를 *선호한다* . @@ -302,9 +302,8 @@ Y는 쿠버네티스가 충족할 규칙이다. 다른 노드도 존재한다면, 스케줄러는 `topology.kubernetes.io/zone=R` 레이블이 있는 노드에는 가급적 해당 파드를 스케줄링하지 않야아 한다. -[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에서 -파드 어피니티와 안티-어피니티에 대한 -많은 예시를 볼 수 있다. +파드 어피니티와 안티-어피니티의 예시에 대해 익숙해지고 싶다면, +[디자인 제안](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)을 참조한다. 파드 어피니티와 안티-어피니티의 `operator` 필드에 `In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다. @@ -472,9 +471,11 @@ spec: ## {{% 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)에 대한 디자인 문서를 읽어본다. +* [노드 어피니티](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)와 + [파드간 어피니티/안티-어피니티](https://git.k8s.io/design-proposals-archive/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/)를 어떻게 사용하는지 알아본다. + + diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index 0feb96eb9a..dbca83de2d 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -97,7 +97,7 @@ kubectl get pod test-pod -o jsonpath='{.spec.overhead}' map[cpu:250m memory:120Mi] ``` -만약 리소스쿼터 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 +만약 [리소스쿼터](/ko/docs/concepts/policy/resource-quotas/) 항목이 정의되어 있다면, 컨테이너의 리소스 요청의 합에는 `overhead` 필드도 추가된다. kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 때, 파드의 `overhead` 와 @@ -196,3 +196,4 @@ sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath * [런타임클래스](/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/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index 8c5f19b8ff..6ed3535659 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -1,72 +1,102 @@ --- - - - - -title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) +# reviewers: +# - bsalamat +# - k82cn +# - ahg-g +title: 리소스 빈 패킹(bin packing) content_type: concept weight: 80 --- -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -kube-scheduler는 `RequestedToCapacityRatioResourceAllocation` -우선 순위 기능을 사용해서 확장된 리소스와 함께 리소스의 빈 패킹이 가능하도록 -구성할 수 있다. 우선 순위 기능을 사용해서 맞춤 요구에 따라 -kube-scheduler를 미세 조정할 수 있다. +kube-scheduler의 [스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins) `NodeResourcesFit`에는, +리소스의 빈 패킹(bin packing)을 지원하는 `MostAllocated`과 `RequestedToCapacityRatio`라는 두 가지 점수 산정(scoring) 전략이 있다. -## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기 +## MostAllocated 전략을 사용하여 빈 패킹 활성화하기 +`MostAllocated` 전략은 리소스 사용량을 기반으로 할당량이 많은 노드를 높게 평가하여 노드에 점수를 매긴다. +각 리소스 유형별로 가중치를 설정하여 노드 점수에 미치는 영향을 조정할 수 있다. -쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 -용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. -이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 -대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. -`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 -`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다. -이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. -`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로 -최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. +`NodeResourcesFit` 플러그인에 대한 `MostAllocated` 전략을 설정하려면, +다음과 유사한 [스케줄러 설정](/ko/docs/reference/scheduling/config)을 사용한다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: +- pluginConfig: + - args: + scoringStrategy: + resources: + - name: cpu + weight: 1 + - name: memory + weight: 1 + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 3 + type: MostAllocated + name: NodeResourcesFit +``` + +기타 파라미터와 기본 구성에 대한 자세한 내용은 +[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs)에 대한 API 문서를 참조한다. + +## RequestedToCapacityRatio을 사용하여 빈 패킹 활성화하기 + +`RequestedToCapacityRatio` 전략은 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 +용량 대비 요청 비율을 기반으로 노드의 점수를 매길 수 있게 한다. +이를 통해 사용자는 적절한 파라미터를 사용하여 확장된 리소스를 빈 팩으로 만들 수 있어 +대규모의 클러스터에서 부족한 리소스의 활용도를 향상시킬 수 있다. 이 전략은 +할당된 리소스의 구성된 기능에 따라 노드를 선호하게 한다. `NodeResourcesFit`점수 기능의 +`RequestedToCapacityRatio` 동작은 [scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy)필드를 +이용하여 제어할 수 있다. +`scoringStrategy` 필드에서 `requestedToCapacityRatioParam`와 `resources`라는 두 개의 파라미터를 +구성할 수 있다. `requestedToCapacityRatioParam`파라미터의 +`shape`를 사용하면 `utilization`과 `score` 값을 기반으로 +최소 요청 혹은 최대 요청된 대로 기능을 조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 구성된다. -다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 -`requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 +다음은 `requestedToCapacityRatio` 를 이용해 +확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 빈 패킹 동작을 설정하는 구성의 예시이다. ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: -# ... - pluginConfig: - - name: RequestedToCapacityRatio - args: - shape: - - utilization: 0 - score: 10 - - utilization: 100 - score: 0 - resources: - - name: intel.com/foo - weight: 3 - - name: intel.com/bar - weight: 5 +- pluginConfig: + - args: + scoringStrategy: + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 3 + requestedToCapacityRatioParam: + shape: + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 + type: RequestedToCapacityRatio + name: NodeResourcesFit ``` kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여 `KubeSchedulerConfiguration` 파일을 참조하면 구성이 스케줄러에 전달된다. -**이 기능은 기본적으로 비활성화되어 있다.** +기타 파라미터와 기본 구성에 대한 자세한 내용은 +[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs)에 대한 API 문서를 참조한다. -### 우선 순위 기능 튜닝하기 +### 점수 기능 튜닝하기 -`shape` 는 `RequestedToCapacityRatioPriority` 기능의 -동작을 지정하는 데 사용된다. +`shape` 는 `RequestedToCapacityRatio` 기능의 동작을 지정하는 데 사용된다. ```yaml shape: @@ -221,3 +251,4 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) - [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)에 대해 더 읽어본다. - [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 대해 더 읽어본다. + diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index f6321e4aa7..423be4f69f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -1,8 +1,8 @@ --- - - - - +# reviewers: +# - davidopp +# - kevin-wangzefeng +# - bsalamat title: 테인트(Taints)와 톨러레이션(Tolerations) content_type: concept weight: 40 @@ -15,8 +15,7 @@ weight: 40 (기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다. _테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. -_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 -스케줄되게 하지만 필수는 아니다. +_톨러레이션_ 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다. 톨러레이션은 스케줄을 허용하지만 보장하지는 않는다. 스케줄러는 그 기능의 일부로서 [다른 매개변수를](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) 고려한다. 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지 않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은 From bffe5659651c5023938fbd18cf783a4c95d211e1 Mon Sep 17 00:00:00 2001 From: Jonghyeok K <83562725+jka236@users.noreply.github.com> Date: Fri, 29 Jul 2022 09:59:12 -0700 Subject: [PATCH 038/202] [ko] Dev 1.24 ko.2 Update from M1 to M10 (#35255) * main page event update * [Ko] M2 update * [Ko] M3 update * [Ko] M4 update * [Ko] M5 Update * [Ko] M6 Update * [Ko] M7 update * [Ko] M8 Update * [Ko] M9 Update * Update content/ko/community/static/cncf-code-of-conduct.md Suggestion from yoonian Co-authored-by: Yoon * Apply suggestions from code review - yoonian Suggestion from yoonian - correcting grammar & spelling Co-authored-by: Yoon * Update content/ko/docs/concepts/architecture/control-plane-node-communication.md Co-authored-by: Yoon Co-authored-by: Yoon --- content/ko/_index.html | 10 ++-- content/ko/community/code-of-conduct.md | 4 +- .../community/static/cncf-code-of-conduct.md | 59 +++++++++++++------ .../control-plane-node-communication.md | 10 ++-- .../ko/docs/concepts/architecture/nodes.md | 2 +- .../concepts/cluster-administration/_index.md | 2 +- .../concepts/cluster-administration/addons.md | 10 ++-- .../manage-deployment.md | 2 +- .../cluster-administration/networking.md | 2 +- 9 files changed, 62 insertions(+), 39 deletions(-) diff --git a/content/ko/_index.html b/content/ko/_index.html index 0925f2ef7e..ddfa38659b 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

- KubeCon Europe (2022년 5월 17~20일) 참가하기 -
-
-
-
KubeCon North America (2022년 10월 24~28일) 참가하기 +
+
+
+
+ KubeCon Europe (2023년 4월 17~21일) 참가하기
diff --git a/content/ko/community/code-of-conduct.md b/content/ko/community/code-of-conduct.md index e0adb28c27..77fe26b43a 100644 --- a/content/ko/community/code-of-conduct.md +++ b/content/ko/community/code-of-conduct.md @@ -8,8 +8,8 @@ community_styles_migrated: true

쿠버네티스는 -CNCF의 행동 강령을 따르고 있습니다. -커밋 214585e +CNCF의 행동 강령을 따르고 있습니다. +커밋 71b12a2 에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다. 만약 최신 버전이 아닌 경우에는 이슈를 제기해 주세요. diff --git a/content/ko/community/static/cncf-code-of-conduct.md b/content/ko/community/static/cncf-code-of-conduct.md index 804c5632fd..9d191a81bb 100644 --- a/content/ko/community/static/cncf-code-of-conduct.md +++ b/content/ko/community/static/cncf-code-of-conduct.md @@ -1,28 +1,42 @@ -## CNCF 커뮤니티 행동 강령 v1.0 + https://github.com/cncf/foundation/blob/main/code-of-conduct.md --> +## CNCF 커뮤니티 행동 강령 v1.1 ### 기여자 행동 강령 -본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의 +CNCF 커뮤니티의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의 커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트, 풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는 모든 분들을 존중할 것을 약속합니다. 우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression), 성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, -또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에 +또는 국적에 상관 없이 모두가 차별 없는 환경에서 CNCF 커뮤니티에 참여할 수 있도록 최선을 다하고 있습니다. +## 범위 +본 행동 강령은 프로젝트 활동 영역 내에서뿐만 아니라 개인이 프로젝트 또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다. + +## CNCF 이벤트 +CNCF 이벤트, 혹은 리눅스 재단에서 이벤트 전문 직원과 운영하는 이벤트는 이벤트 페이지에 명시된 Linux Foundation [이벤트 행동 강령](https://events.linuxfoundation.org/code-of-conduct)에 의거하여 운영됩니다. 해당 행동 강령은 CNCF의 행동 강령과 함께 사용하도록 고안되었습니다. + +## 우리의 원칙 + +긍정적인 환경을 조성하는 행위는 다음과 같습니다. +* 타인에게 친절과 공감 실천 +* 타인의 의견, 관점, 그리고 경험에 대한 포용 +* 건설적 피드백에 대한 수용 +* 실수에 대한 책임과 사과, 그리고 경험을 통한 배움 +* 개인의 최선이 아닌 커뮤니티 전반의 선을 위한 노력 + + 참여자에게 금지하는 행위의 예시는 다음과 같습니다. -- 성적인 언어 또는 이미지 사용 -- 인신 공격 -- 도발적이거나 모욕/경멸적인 코멘트 -- 공개적이거나 사적인 괴롭힘 -- 타인의 주소 및 전자주소와 같은 개인 정보의 - 동의 없는 공개 -- 기타 비윤리적이거나 비전문적인 행동 +* 성적인 언어 또는 이미지 사용, 혹은 그 외 성적으로 부적절한 행동 +* 선동적, 모욕적, 경멸적 언사, 그리고 개인적 혹은 정치적 공격 +* 공개적이거나 사적인 괴롭힘 +* 타인의 주소 및 전자주소와 같은 개인 정보의 동의 없는 공개 +* 기타 비윤리적이거나 비전문적인 행동 프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit), 코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정, @@ -31,15 +45,22 @@ 행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서 영구적으로 제적될 수 있습니다. -본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트 -또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다. +## 신고 +쿠버네티스 커뮤니티에서 발생하는 사건들은 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 신고시 3일 내 회신을 받을 수 있습니다. -쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 으로 문의해 주시기 바랍니다. +기타 다른 프로젝트에 관해서는 CNCF 직원에게 이메일 으로 문의하십시오. -본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서 -제공하는 버전 1.2.0을 적용하였으며, 해당 내용은 -https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다. +CNCF는 외부 중재자로 Mishi Choudhary 를 두고 있습니다. 외부 중재자는 CNCF 직원의 안내에 따라 의뢰 가능합니다. 보통의 경우 로 직접 연락하는 것을 추천합니다. -### CNCF 이벤트 행동 강령 +쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 으로 문의하십시오. -CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다. +## 집행 +쿠버네티 프로젝트의 [행동 강령 위원회](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)가 행동 강령 발행을 시행합니다. 기타 프로젝트에 관하여는 CNCF가 행동강력 발행을 시행합니다. + +양 기관은 처벌 없는 문제 해결을 추구합니다. 하지만 CNCF의 재량에 따라 회원 혹은 프로젝트를 퇴출시킬 수 있습니다. + +### 확인 + +본 행동 강령은 기여자 서약(https://contributor-covenant.org)에서 +제공하는 버전 2.0을 적용하였으며, 해당 내용은 +https://contributor-covenant.org/version/2/0/code_of_conduct/ 에서 확인할 수 있습니다. diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 00f99d07ea..9846e956f2 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -8,7 +8,7 @@ aliases: -이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. +이 문서는 API 서버와 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. @@ -37,7 +37,7 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증 API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. * 파드에 대한 로그를 가져온다. -* 실행 중인 파드에 (kubectl을 통해) 연결한다. +* 실행 중인 파드에 (보통의 경우 kubectl을 통해) 연결한다. * kubelet의 포트-포워딩 기능을 제공한다. 이 연결은 kubelet의 HTTPS 엔드포인트에서 종료된다. 기본적으로, API 서버는 kubelet의 서빙(serving) 인증서를 확인하지 않으므로, 연결이 중간자(man-in-the-middle) 공격의 대상이 되며, 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **안전하지 않다** . @@ -58,9 +58,11 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다. 이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다. -SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. +{{< note >}} +SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안 된다. [Konnectivity 서비스](#konnectivity-service)가 SSH 통신 채널을 대체한다. +{{< note >}} -### Konnectivity 서비스 +### Konnectivity 서비스 {#konnectivity-service} {{< feature-state for_k8s_version="v1.18" state="beta" >}} diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 76b1801daa..54a5bdb137 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -654,6 +654,6 @@ kubelet은 `LimitedSwap` 설정과 같은 행동을 * 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다. * [노드에 대한 API 정의](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)를 읽어본다. -* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) +* 아키텍처 디자인 문서의 [노드](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) 섹션을 읽어본다. * [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다. diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index 83feab60ba..6f90b3a1bd 100644 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -63,7 +63,7 @@ no_list: true ### kubelet 보안 * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) - * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [TLS 부트스트래핑(bootstrapping)](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) * [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) ## 선택적 클러스터 서비스 diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 2d758cce13..0c2cd0f4fa 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -18,19 +18,19 @@ content_type: concept * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다. * [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다. * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다. -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다. +* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다. * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다. -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. +* [CNI-Genie](https://github.com/cni-genie/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. * [Contiv](https://contivpp.io/)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. -* Multus는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다. +* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)는 쿠버네티스의 다중 네트워크 지원을 위한 멀티 플러그인이며, 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)과 쿠버네티스 상의 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드를 지원한다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)은 OVN 기반의 CNI 컨트롤러 플러그인으로 클라우드 네이티브 기반 서비스 기능 체인(Service function chaining(SFC)), 다중 OVN 오버레이 네트워킹, 동적 서브넷 생성, 동적 가상 네트워크 생성, VLAN 공급자 네트워크, 직접 공급자 네트워크와 멀티 클러스터 네트워킹의 엣지 기반 클라우드 등 네이티브 워크로드에 이상적인 멀티 네티워크 플러그인이다. -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) 컨테이너 플러그인(NCP)은 VMware NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 간의 통합은 물론 NSX-T와 PKS(Pivotal 컨테이너 서비스) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)는 가시성과 보안 모니터링 기능을 통해 쿠버네티스 파드와 비-쿠버네티스 환경 간에 폴리시 기반 네트워킹을 제공하는 SDN 플랫폼이다. -* **Romana**는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. Kubeadm 애드온 설치에 대한 세부 정보는 [여기](https://github.com/romana/romana/tree/master/containerize)에 있다. +* [Romana](https://github.com/romana)는 [네트워크폴리시 API](/ko/docs/concepts/services-networking/network-policies/)도 지원하는 파드 네트워크용 Layer 3 네트워킹 솔루션이다. * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)은 네트워킹 및 네트워크 폴리시를 제공하고, 네트워크 파티션의 양면에서 작업을 수행하며, 외부 데이터베이스는 필요하지 않다. ## 서비스 검색 diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index cd52e8ba4b..eae731409e 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -454,7 +454,7 @@ deployment.apps/my-nginx scaled kubectl edit deployment/my-nginx ``` -이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/concepts/workloads/controllers/deployment/)를 방문한다. +이것으로 끝이다! 디플로이먼트는 배포된 nginx 애플리케이션을 배후에서 점차적으로 업데이트한다. 업데이트되는 동안 특정 수의 이전 레플리카만 중단될 수 있으며, 원하는 수의 파드 위에 특정 수의 새 레플리카만 생성될 수 있다. 이에 대한 더 자세한 내용을 보려면, [디플로이먼트 페이지](/ko/docs/tasks/debug/debug-application/debug-running-pod/)를 방문한다. diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index bfb1c67f9e..e071d96ca4 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -202,5 +202,5 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 ## {{% heading "whatsnext" %}} 네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은 -[네트워킹 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)에 +[네트워킹 디자인 문서](https://git.k8s.io/design-proposals-archive/network/networking.md)에 자세히 설명되어 있다. From 43fe55c9169c25161761b3e11645987dc9bae94e Mon Sep 17 00:00:00 2001 From: having-dlrow Date: Fri, 22 Jul 2022 19:27:32 +0900 Subject: [PATCH 039/202] update outdated korean files in dev-1.24-ko.2 (M90-M93) --- .../tasks/debug/debug-cluster/resource-metrics-pipeline.md | 4 ++-- .../tasks/debug/debug-cluster/resource-usage-monitoring.md | 7 +++++-- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md index 1a7c6716ef..678f0fd60a 100644 --- a/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug/debug-cluster/resource-metrics-pipeline.md @@ -173,7 +173,7 @@ curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/po [API 집계(aggregation) 계층](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)을 활성화하고 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)를 등록해야 한다. -메트릭 API에 대해 더 알아보려면, [리소스 메트릭 API 디자인](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md), +메트릭 API에 대해 더 알아보려면, [리소스 메트릭 API 디자인](https://git.k8s.io/design-proposals-archive/instrumentation/resource-metrics-api.md), [metrics-server 저장소](https://github.com/kubernetes-sigs/metrics-server) 및 [리소스 메트릭 API](https://github.com/kubernetes/metrics#resource-metrics-api)를 참고한다. @@ -237,7 +237,7 @@ metrics-server에 대한 더 많은 정보는 또한 다음을 참고할 수도 있다. -* [metrics-server 디자인](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md) +* [metrics-server 디자인](https://git.k8s.io/design-proposals-archive/instrumentation/metrics-server.md) * [metrics-server 자주 묻는 질문](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md) * [metrics-server 알려진 이슈](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md) * [metrics-server 릴리스](https://github.com/kubernetes-sigs/metrics-server/releases) diff --git a/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md index 396538b395..02ac07e805 100644 --- a/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug/debug-cluster/resource-usage-monitoring.md @@ -42,8 +42,11 @@ Kubelet은 쿠버네티스 마스터와 노드 간의 다리 역할을 하면서 Kubelet은 각각의 파드를 해당하는 컨테이너에 매치시키고 컨테이너 런타임 인터페이스를 통해 컨테이너 런타임에서 개별 컨테이너의 사용량 통계를 가져온다. -Kubelet은 이 정보를 레거시 도커와의 통합을 위해 kubelet에 통합된 cAdvisor를 통해 가져온다. -그 다음으로 취합된 파드 리소스 사용량 통계를 metric-server 리소스 메트릭 API를 통해 노출한다. +컨테이너를 구현하기 위해 리눅스 cgroup 및 네임스페이스를 활용하는 컨테이너 런타임을 사용하며, +해당 컨테이너 런타임이 사용 통계치를 퍼블리싱 하지 않는 경우, +kubelet은 해당 통계치를 ([cAdvisor](https://github.com/google/cadvisor)의 코드 사용하여) 직접 조회 할 수 있다. +이런 통계가 어떻게 도착하든 kubelet은 취합된 파드 리소스 사용량 통계를 +metric-server 리소스 메트릭 API를 통해 노출한다. 이 API는 kubelet의 인증이 필요한 읽기 전용 포트 상의 `/metrics/resource/v1beta1`에서 제공된다. From 6efed264cb4a9d191253770b4d76b54e76fd42a9 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 29 Jul 2022 12:11:42 +0900 Subject: [PATCH 040/202] [ko] Remove files deleted from upstream --- .../extend-kubernetes/service-catalog.md | 232 ---------------- .../docs/reference/glossary/service-broker.md | 22 -- .../kubeadm/adding-windows-nodes.md | 256 ------------------ .../ko/docs/tasks/service-catalog/_index.md | 5 - .../install-service-catalog-using-sc.md | 78 ------ 5 files changed, 593 deletions(-) delete mode 100644 content/ko/docs/concepts/extend-kubernetes/service-catalog.md delete mode 100644 content/ko/docs/reference/glossary/service-broker.md delete mode 100644 content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md delete mode 100644 content/ko/docs/tasks/service-catalog/_index.md delete mode 100644 content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md deleted file mode 100644 index 6d2bd2ee39..0000000000 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ /dev/null @@ -1,232 +0,0 @@ ---- -title: 서비스 카탈로그 - - -content_type: concept -weight: 40 ---- - - -{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}} - -[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)에 정의된 서비스 브로커는 AWS, GCP 또는 Azure와 같은 타사 클라우드 공급자에 의해 제공되고 관리되는 매니지드 서비스의 세트에 대한 엔드포인트다. -매니지드 서비스의 예로 Microsoft Azure Cloud Queue, Amazon Simple Quere Service, Google Cloud Pub/Sub이 있으나 애플리케이션에서 사용할 수 있는 모든 소프트웨어 제품일 수 있다. - -{{< glossary_tooltip text="클러스터 오퍼레이터" term_id="cluster-operator" >}}는 서비스 카탈로그를 사용하여 서비스 브로커가 제공하는 매니지드 서비스 목록을 탐색하거나 매니지드 서비스 인스턴스를 프로비저닝하고, 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있도록 바인딩할 수 있다. - - - - - -## 유스케이스 예제 - -한 {{< glossary_tooltip text="애플리케이션 개발자" term_id="application-developer" >}}가 쿠버네티스 클러스터 내에서 실행되는 애플리케이션 중 일부로 메시지 큐를 사용하기를 원한다. -그러나 그러한 서비스에 대한 설정과 관리에는 부담이 따른다. -다행히 서비스 브로커를 통해 메시지 큐를 매니지드 서비스로 제공하는 클라우드 공급자가 있다. - -클러스터 운영자는 서비스 카탈로그를 설정하고 이를 이용하여 클라우드 공급자의 서비스 브로커와 통신하여 메시지 큐 서비스의 인스턴스를 프로비저닝하고 쿠버네티스 클러스터 내의 애플리케이션에서 사용할 수 있게 한다. -따라서 애플리케이션 개발자는 메시지 큐의 세부 구현 또는 관리에 신경 쓸 필요가 없다. -애플리케이션은 메시지 큐에 서비스로 접속할 수 있다. - -## 아키텍처 - -서비스 카탈로그는 [오픈 서비스 브로커 API](https://github.com/openservicebrokerapi/servicebroker)를 사용하여 쿠버네티스 API 서버가 초기 프로비저닝을 협상하고 애플리케이션이 매니지드 서비스를 사용하는데 필요한 자격 증명을 검색하는 중개자 역할을 하는 서비스 브로커와 통신한다. - -이는 [CRD 기반](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/#커스텀-리소스) 아키텍처를 사용해서 구현되었다. - -
- -![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg) - - -### API 리소스 - -서비스 카탈로그는 `servicecatalog.k8s.io` API를 설치하고 다음 쿠버네티스 리소스를 제공한다. - -* `ClusterServiceBroker`: 서버 연결 세부 사항을 캡슐화한, 서비스 브로커의 클러스터 내부 대표. -이들은 클러스터 내에서 새로운 유형의 매니지드 서비스를 사용할 수 있도록 하려는 클러스터 운영자가 만들고 관리한다. -* `ClusterServiceClass`: 특정 서비스 브로커가 제공하는 매니지드 서비스. -새로운 `ClusterServiceBroker` 리소스가 클러스터에 추가되면 서비스 카탈로그 컨트롤러는 서비스 브로커에 연결해서 사용 가능한 매니지드 서비스 목록을 얻는다. 그 다음 각 매니지드 서비스에 해당하는 새로운 `ClusterServiceClass` 리소스를 만든다. -* `ClusterServicePlan`: 매니지드 서비스의 특별 요청. 예를 들어, 매니지드 서비스는 무료 혹은 유료 티어와 같이 사용 가능한 서로 다른 상품이 있거나, SSD 스토리지를 사용하거나 더 많은 리소스를 갖는 등 다른 구성 옵션을 가질 수 있다. `ClusterServiceClass`와 유사하게, 새로운 `ClusterServiceBroker`가 클러스터에 추가되면, 서비스 카탈로그는 각 매니지드 서비스에 사용 가능한 서비스 플랜에 해당하는 새로운 `ClusterServicePlan` 리소스를 작성한다. -* `ServiceInstance`: `ClusterServiceClass`의 프로비저닝된 인스턴스. -클러스터 운영자가 하나 이상의 클러스터 애플리케이션에서 사용할 수 있도록 매니지드 서비스의 특정 인스턴스를 사용하기 위해 생성한다. -새로운 `ServiceInstance`리소스가 생성되면, 서비스 카탈로그 컨트롤러는 해당 서비스 브로커에 연결하여 서비스 인스턴스를 프로비저닝하도록 지시한다. -* `ServiceBinding`: `ServiceInstance`에 대한 자격 증명에 액세스한다. -자신의 애플리케이션이 `ServiceInstance`를 사용하기를 원하는 클러스터 운영자가 이들을 생성한다. -서비스 카탈로그 컨트롤러는 생성 시 파드에 마운트될 수 있는 서비스 인스턴스에 대한 연결 세부 정보와 자격 증명이 포함된 쿠버네티스 '시크릿(secret)'을 생성한다. - -### 인증 - -서비스 카탈로그는 다음의 인증 방법을 지원한다. - -* 기본 (username/password) -* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750) - -## 사용법 - -클러스터 운영자는 서비스 카탈로그 API 리소스를 사용하여 매니지드 서비스를 프로비저닝하여 쿠버네티스 클러스터 내에서 사용할 수 있게 한다. 관련 단계는 다음과 같다. - -1. 서비스 브로커에서 사용 가능한 매니지드 서비스와 서비스 플랜을 나열. -1. 매니지드 서비스의 새 인스턴스 프로비저닝. -1. 연결 자격 증명을 반환하는 매니지드 서비스에 바인딩. -1. 연결 자격 증명을 애플리케이션에 매핑. - -### 매니지드 서비스와 서비스 플랜 나열 - -먼저, 클러스터 운영자는 `servicecatalog.k8s.io` 그룹 내에 `ClusterServiceBroker` 리소스를 생성해야 한다. 이 리소스는 서비스 브로커 엔드포인트에 접근하는데 필요한 URL과 연결 세부 사항을 포함한다. - -다음은 `ClusterServiceBroker` 리소스 예시이다. - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ClusterServiceBroker -metadata: - name: cloud-broker -spec: - # 서비스 브로커의 엔드포인트를 가리킨다. (이 예시는 동작하지 않는 URL이다.) - url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default - ##### - # bearer 토큰 정보 혹은 TLS용 caBundle과 같은 - # 서비스 브로커와 통신하는데 사용될 수 있는 값을 여기에 추가할 수 있다. - ##### -``` - -다음은 서비스 브로커에서 사용 가능한 매니지드 서비스와 플랜을 나열하는 단계를 설명하는 시퀀스 다이어그램이다. - -![List Services](/images/docs/service-catalog-list.svg) - -1. `ClusterServiceBroker` 리소스가 서비스 카탈로그에 추가되면, 사용 가능한 서비스 목록에 대한 외부 서비스 브로커에 대한 호출을 발생시킨다. -1. 서비스 브로커는 사용 가능한 매니지드 서비스 목록과 서비스 플랜 목록을 반환한다. 이 목록은 각각 로컬 `ClusterServiceClass`와 `ClusterServicePlan` 리소스로 캐시된다. -1. 그런 다음 클러스터 운영자는 다음의 명령어를 사용하여 가용한 관리 서비스 목록을 얻을 수 있다. - - kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - - 아래와 같은 형태의 서비스 이름 목록이 출력된다. - - SERVICE NAME EXTERNAL NAME - 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service - ... ... - - 또한 다음의 명령어를 사용하여 가용한 서비스 플랜을 볼 수 있다. - - kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - - 아래와 같은 형태의 플랜 이름 목록이 출력된다. - - PLAN NAME EXTERNAL NAME - 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name - ... ... - - -### 새 인스턴스 프로비저닝 - -클러스터 운영자는 `ServiceInstance` 리소스를 생성하여 새 인스턴스 프로비저닝을 시작할 수 있다. - -다음은 `ServiceInstance` 리소스의 예시이다. - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ServiceInstance -metadata: - name: cloud-queue-instance - namespace: cloud-apps -spec: - # 이전에 반환된 서비스 중 하나를 참조 - clusterServiceClassExternalName: cloud-provider-service - clusterServicePlanExternalName: service-plan-name - ##### - # 이곳에 서비스 브로커가 사용할 수 있는 - # 파라미터를 추가할 수 있다. - ##### -``` - -다음의 시퀀스 다이어그램은 매니지드 서비스의 새 인스턴스 프로비저닝과 관련된 일련의 단계를 보여준다. - -![Provision a Service](/images/docs/service-catalog-provision.svg) - -1. `ServiceInstance` 리소스가 생성되면, 서비스 카탈로그는 서비스 인스턴스를 프로비저닝하기 위해 외부의 서비스 브로커 호출을 초기화한다. -1. 서비스 브로커는 새로운 매니지드 서비스 인스턴스를 생성하고 HTTP 응답을 리턴한다. -1. 그 후 클러스터 운영자는 인스턴스 상태가 준비되었는지 점검할 수 있다. - -### 매니지드 서비스에 바인딩 - -새 인스턴스가 프로비저닝된 후, 클러스터 운영자는 애플리케이션이 서비스를 사용하는데 필요한 자격 증명을 얻기 위해 매니지드 서비스에 바인드해야 한다. 이것은 `ServiceBinding` 리소스를 생성하는 것으로 이루어진다. - -다음은 `ServiceBinding` 리소스의 예시다. - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ServiceBinding -metadata: - name: cloud-queue-binding - namespace: cloud-apps -spec: - instanceRef: - name: cloud-queue-instance - ##### - # 서비스 브로커가 사용할 수 있는 secretName, 서비스 어카운트 파라미터 등의 - # 추가 정보를 여기에 추가할 수 있다. - ##### -``` - -다음의 시퀀스 다이어그램은 매니지드 서비스 인스턴스에 바인딩하는 단계를 보여준다. - -![Bind to a managed service](/images/docs/service-catalog-bind.svg) - -1. `ServiceBinding`이 생성된 이후, 서비스 카탈로그는 서비스 인스턴스와 바인딩하는데 필요한 정보를 요청하는 외부 서비스 브로커를 호출한다. -1. 서비스 브로커는 적절한 서비스 어카운트에 대한 애플리케이션 권한/역할을 활성화한다. -1. 서비스 브로커는 매니지드 서비스 인스턴스에 연결하고 액세스하는데 필요한 정보를 리턴한다. 이는 제공자와 서비스에 특화되어 있으므로 서비스 프로바이더와 매니지드 서비스에 따라 다를 수 있다. - -### 연결 자격 증명 매핑 - -바인딩 후 마지막 단계는 연결 자격 증명과 서비스 특화 정보를 애플리케이션에 매핑하는 것이다. -이런 정보는 클러스터의 애플리케이션이 액세스하여 매니지드 서비스와 직접 연결하는데 사용할 수 있는 시크릿으로 저장된다. - -
- -![Map connection credentials](/images/docs/service-catalog-map.svg) - -#### 파드 구성 파일 - -이 매핑을 수행하는 한 가지 방법은 선언적 파드 구성을 사용하는 것이다. - -다음 예시는 서비스 자격 증명을 애플리케이션에 매핑하는 방법을 설명한다. `sa-key`라는 키는 `provider-cloud-key`라는 볼륨에 저장되며, 애플리케이션은 이 볼륨을 `/var/secrets/provider/key.json`에 마운트한다. 환경 변수 `PROVIDER_APPLICATION_CREDENTIALS`는 마운트된 파일의 값에서 매핑된다. - -```yaml -... - spec: - volumes: - - name: provider-cloud-key - secret: - secretName: sa-key - containers: -... - volumeMounts: - - name: provider-cloud-key - mountPath: /var/secrets/provider - env: - - name: PROVIDER_APPLICATION_CREDENTIALS - value: "/var/secrets/provider/key.json" -``` - -다음 예시는 시크릿 값을 애플리케이션 환경 변수에 매핑하는 방법을 설명한다. 이 예시에서 메시지 큐 토픽 이름은 `topic` 라는 키의 `provider-queue-credentials` 시크릿에서 환경 변수 `TOPIC`에 매핑된다. - - -```yaml -... - env: - - name: "TOPIC" - valueFrom: - secretKeyRef: - name: provider-queue-credentials - key: topic -``` - - - - -## {{% heading "whatsnext" %}} - -* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. -* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 -* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 diff --git a/content/ko/docs/reference/glossary/service-broker.md b/content/ko/docs/reference/glossary/service-broker.md deleted file mode 100644 index bd67184898..0000000000 --- a/content/ko/docs/reference/glossary/service-broker.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: 서비스 브로커(Service Broker) -id: service-broker -date: 2018-04-12 -full_link: -short_description: > - 서드파티에서 제공하고 유지 관리하는 일련의 매니지드 서비스에 대한 엔드포인트이다. - -aka: -tags: -- extension ---- - 서드파티에서 제공하고 유지 관리하는 일련의 {{< glossary_tooltip text="매니지드 서비스" term_id="managed-service" >}}에 대한 엔드포인트이다. - - - -{{< glossary_tooltip text="서비스 브로커" term_id="service-broker" >}}는 -[오픈 서비스 브로커 API 명세](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)를 -구현하고 애플리케이션이 매니지드 서비스를 사용할 수 있도록 표준 인터페이스를 제공한다. -[서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)는 -서비스 브로커가 제공하는 매니지드 서비스의 목록과 프로비전, 바인딩하는 방법을 제공한다. - diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md deleted file mode 100644 index a950d50b95..0000000000 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ /dev/null @@ -1,256 +0,0 @@ ---- - - - - - -title: 윈도우 노드 추가 -min-kubernetes-server-version: 1.17 -content_type: tutorial -weight: 30 ---- - - - -{{< feature-state for_k8s_version="v1.18" state="beta" >}} - -쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다. - - -## {{% heading "prerequisites" %}} - {{< version-check >}} - -* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면 -[윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다. -VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다. - -* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다. - - - - -## {{% heading "objectives" %}} - - -* 클러스터에 윈도우 노드 등록 -* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성 - - - - - - -## 시작하기: 클러스터에 윈도우 노드 추가 - -### 네트워킹 구성 - -리눅스 기반 쿠버네티스 컨트롤 플레인 노드가 있으면 네트워킹 솔루션을 선택할 수 있다. 이 가이드는 VXLAN 모드의 플란넬(Flannel)을 사용하는 방법을 짧막하게 보여준다. - -#### 플란넬 구성 - -1. 플란넬을 위한 쿠버네티스 컨트롤 플레인 준비 - - 클러스터의 쿠버네티스 컨트롤 플레인에서 약간의 준비가 필요하다. 플란넬을 사용할 때 iptables 체인에 브릿지된 IPv4 트래픽을 활성화하는 것을 권장한다. 아래 명령을 모든 리눅스 노드에서 실행해야만 한다. - - ```bash - sudo sysctl net.bridge.bridge-nf-call-iptables=1 - ``` - -1. 리눅스용 플란넬 다운로드 및 구성 - - 가장 최근의 플란넬 매니페스트를 다운로드한다. - - ```bash - wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml - ``` - - VNI를 4096으로 설정하고 포트를 4789로 설정하려면 플란넬 매니페스트의 `net-conf.json` 섹션을 수정한다. 다음과 같을 것이다. - - ```json - net-conf.json: | - { - "Network": "10.244.0.0/16", - "Backend": { - "Type": "vxlan", - "VNI": 4096, - "Port": 4789 - } - } - ``` - - {{< note >}}리눅스의 플란넬이 윈도우의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를 - 참고한다.{{< /note >}} - - {{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}} - -1. 플란넬 매니페스트 적용 및 유효성 검사 - - 플란넬 구성을 적용해보자. - - ```bash - kubectl apply -f kube-flannel.yml - ``` - - 몇 분 후에, 플란넬 파드 네트워크가 배포되었다면 모든 파드가 실행 중인 것으로 표시된다. - - ```bash - kubectl get pods -n kube-system - ``` - - 출력 결과에 리눅스 flannel 데몬셋(DaemonSet)이 실행 중인 것으로 나와야 한다. - - ``` - NAMESPACE NAME READY STATUS RESTARTS AGE - ... - kube-system kube-flannel-ds-54954 1/1 Running 0 1m - ``` - -1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가 - - 이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한 - kube-proxy 버전을 얻으려면, 이미지의 태그를 - 대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만, - 사용자의 배포에 맞게 버전을 조정해야 한다. - - ```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 >}} - host-gateway를 사용하는 경우 https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml 을 대신 사용한다. - {{< /note >}} - - {{< note >}} -윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다. - -```powershell -wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" -``` - -그리고, 이에 따라 인터페이스를 지정해야 한다. - -```bash -# 예시 -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) - -{{< note >}} -윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의 -높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다. -{{< /note >}} - -{{< tabs name="tab-windows-kubeadm-runtime-installation" >}} - -{{% tab name="CRI-containerD" %}} - -#### containerD 설치 - -```powershell -curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/Install-Containerd.ps1 -.\Install-Containerd.ps1 -``` - -{{< note >}} -특정 버전의 containerD를 설치하려면 -ContainerDVersion를 사용하여 버전을 지정한다. - -```powershell -# 예 -.\Install-Containerd.ps1 -ContainerDVersion 1.4.1 -``` - -윈도우 노드에서 이더넷(예: "Ethernet0 2")이 아닌 다른 인터페이스를 사용하는 경우, `-netAdapterName` 으로 이름을 지정한다. - -```powershell -# 예 -.\Install-Containerd.ps1 -netAdapterName "Ethernet0 2" -``` - -{{< /note >}} - -#### wins, kubelet 및 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 -``` - -kubeadm이 CRI 엔드포인트와 통신하기 위해 필요한 -[`crictl`을 cri-tools 패키지로부터 설치한다](https://github.com/kubernetes-sigs/cri-tools). - -#### `kubeadm` 실행하여 노드에 조인 - - 컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다. - 이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command` - (컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다. - -{{% /tab %}} - -{{% tab name="Docker Engine" %}} - -#### Docker Engine 설치 - -`컨테이너` 기능 설치 - -```powershell -Install-WindowsFeature -Name containers -``` - -도커 설치에 대한 -자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker)에서 확인할 수 있다. - -kubelet이 CRI 호환 엔드포인트를 통해 도커와 통신하기 위해 필요한 -[cri-dockerd를 설치](https://github.com/Mirantis/cri-dockerd)한다. - -{{< note >}} -도커 엔진은 컨테이너 런타임이 쿠버네티스와 호환되기 위한 요구 사항인 -[CRI](/ko/docs/concepts/architecture/cri/)를 만족하지 않는다. -이러한 이유로, 추가 서비스인 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)가 설치되어야 한다. -cri-dockerd는 쿠버네티스 버전 1.24부터 kubelet에서 [제거](/dockershim/)된 -기존 내장 도커 엔진 지원을 기반으로 한 프로젝트이다. -{{< /note >}} - -kubeadm이 CRI 엔드포인트와 통신하기 위해 필요한 -`crictl`을 [cri-tools 프로젝트](https://github.com/kubernetes-sigs/cri-tools)로부터 설치한다. - -#### wins, kubelet 및 kubeadm 설치 - -```PowerShell -curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 -.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -``` - -#### `kubeadm` 실행하여 노드에 조인 - -컨트롤 플레인 호스트에서 `kubeadm init` 실행할 때 제공된 명령을 사용한다. -이 명령이 더 이상 없거나, 토큰이 만료된 경우, `kubeadm token create --print-join-command` -(컨트롤 플레인 호스트에서)를 실행하여 새 토큰 및 조인 명령을 생성할 수 있다. - -{{% /tab %}} - -{{< /tabs >}} - -### 설치 확인 - -이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다. - -```bash -kubectl get nodes -o wide -``` - -새 노드가 `NotReady` 상태인 경우 플란넬 이미지가 여전히 다운로드 중일 수 있다. -`kube-system` 네임스페이스에서 flannel 파드를 확인하여 이전과 같이 진행 상황을 확인할 수 있다. - -```shell -kubectl -n kube-system get pods -l app=flannel -``` - -flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드를 처리할 수 있어야 한다. - -## {{% heading "whatsnext" %}} - -- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes) diff --git a/content/ko/docs/tasks/service-catalog/_index.md b/content/ko/docs/tasks/service-catalog/_index.md deleted file mode 100644 index bc8920240f..0000000000 --- a/content/ko/docs/tasks/service-catalog/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "서비스 카탈로그" -description: 서비스 카탈로그 익스텐션(extension) API를 설치한다. -weight: 150 ---- diff --git a/content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md deleted file mode 100644 index e7af324ddf..0000000000 --- a/content/ko/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: SC로 서비스 카탈로그 설치하기 -content_type: task ---- - - -{{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}} - -GCP [서비스 카탈로그 설치 프로그램](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) -도구로 쿠버네티스 클러스터에 서비스 카탈로그를 쉽게 설치하거나 제거하여 -Google Cloud 프로젝트에 연결할 수 있다. - -서비스 카탈로그는 Google Cloud뿐 아니라 모든 종류의 관리형 서비스와 함께 작동할 수 있다. - -## {{% heading "prerequisites" %}} - -* [서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)의 핵심 개념을 이해한다. -* [Go 1.6+](https://golang.org/dl/)를 설치하고 `GOPATH`를 설정한다. -* SSL 아티팩트 생성에 필요한 [cfssl](https://github.com/cloudflare/cfssl) 도구를 설치한다. -* 서비스 카탈로그에는 Kubernetes 버전 1.7 이상이 필요하다. -* [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 사용하여 Kubernetes 버전 1.7 이상의 클러스터에 연결하도록 구성한다. -* kubectl 사용자는 서비스 카탈로그를 설치하기 위해 *cluster-admin* 역할에 바인딩되어야 한다. 이것이 사실인지 확인하려면 다음 명령을 실행한다. - - kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= - - - - - -## 로컬 환경에 `sc` 설치하기 - -설치 프로그램은 로컬 컴퓨터에서 `sc`라는 CLI 도구로 실행된다. - -`go get`을 사용하여 설치한다. - -```shell -go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc -``` - -`sc`는 이제 `GOPATH/bin` 디렉토리에 설치되어야 한다. - -## 쿠버네티스 클러스터에 서비스 카탈로그 설치하기 - -먼저 명령을 실행하여 모든 종속성이 설치되었는지 확인한다. - -```shell -sc check -``` - -확인에 성공하면 다음을 반환해야 한다. - -``` -Dependency check passed. You are good to go. -``` - -그런 다음 설치 명령을 실행하고 백업에 사용할 `storageclass`를 지정한다. - -```shell -sc install --etcd-backup-storageclass "standard" -``` - -## 서비스 카탈로그 제거하기 - -`sc` 도구를 사용하여 쿠버네티스 클러스터에서 서비스 카탈로그를 제거하려면 다음을 실행한다. - -```shell -sc uninstall -``` - - - - -## {{% heading "whatsnext" %}} - -* [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 -* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 - - From 578f4af30cbc7ee00205b4749f822a5200d98286 Mon Sep 17 00:00:00 2001 From: Jinny Park Date: Sat, 23 Jul 2022 17:26:32 +0900 Subject: [PATCH 041/202] [ko]Fix outdated files in dev-1.24-ko.2 (M36-M39) --- .../concepts/storage/ephemeral-volumes.md | 14 ++-- .../concepts/storage/persistent-volumes.md | 25 ++++--- .../docs/concepts/storage/storage-classes.md | 12 ++-- content/ko/docs/concepts/storage/volumes.md | 68 +++++++++++++++---- 4 files changed, 84 insertions(+), 35 deletions(-) diff --git a/content/ko/docs/concepts/storage/ephemeral-volumes.md b/content/ko/docs/concepts/storage/ephemeral-volumes.md index 0360d4e59c..5ed4042842 100644 --- a/content/ko/docs/concepts/storage/ephemeral-volumes.md +++ b/content/ko/docs/concepts/storage/ephemeral-volumes.md @@ -1,10 +1,10 @@ --- - - - - - - +## reviewers: +## - jsafrane +## - saad-ali +## - msau42 +## - xing-yang +## - pohly title: 임시 볼륨 content_type: concept weight: 30 @@ -207,7 +207,7 @@ spec: 즉각적인 바인딩을 사용하는 경우, 스케줄러는 볼륨이 사용 가능해지는 즉시 해당 볼륨에 접근 가능한 노드를 선택하도록 강요받는다. -[리소스 소유권](/ko/docs/concepts/architecture/garbage-collection/#owners-dependents) 관점에서, +[리소스 소유권](/docs/concepts/workloads/controllers/garbage-collection/#owners-dependents) 관점에서, 일반 임시 스토리지를 갖는 파드는 해당 임시 스토리지를 제공하는 퍼시스턴트볼륨클레임의 소유자이다. 파드가 삭제되면, 쿠버네티스 가비지 콜렉터는 해당 PVC를 삭제하는데, diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 857d25e8ae..28034a2d5a 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -1,10 +1,10 @@ --- - - - - - - +## reviewers: +## - jsafrane +## - saad-ali +## - thockin +## - msau42 +## - xing-yang title: 퍼시스턴트 볼륨 feature: title: 스토리지 오케스트레이션 @@ -540,6 +540,15 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다. * RWX - ReadWriteMany * RWOP - ReadWriteOncePod +{{< note >}} +쿠버네티스는 볼륨 접근 모드를 이용해 퍼시스턴트볼륨클레임과 퍼시스턴트볼륨을 연결한다. +경우에 따라 볼륨 접근 모드는 퍼시스턴트볼륨을 탑재할 수 있는 위치도 제한한다. +볼륨 접근 모드는 스토리지를 마운트 한 후에는 쓰기 보호를 적용하지 않는다. +접근 모드가 ReadWriteOnce, ReadOnlyMany 혹은 ReadWriteMany로 지정된 경우에도 접근 모드는 볼륨에 제약 조건을 설정하지 않는다. +예를 들어 퍼시스턴트볼륨이 ReadOnlyMany로 생성되었다 하더라도, 해당 퍼시스턴트 볼륨이 읽기 전용이라는 것을 보장하지 않는다. +만약 접근 모드가 ReadWriteOncePod로 지정된 경우, 볼륨에 제한이 설정되어 단일 파드에만 마운트 할 수 있게 된다. +{{< /note >}} + > __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다. @@ -673,7 +682,7 @@ spec: ### 리소스 -파드처럼 클레임은 특정 수량의 리소스를 요청할 수 있다. 이 경우는 스토리지에 대한 요청이다. 동일한 [리소스 모델](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md)이 볼륨과 클레임 모두에 적용된다. +파드처럼 클레임은 특정 수량의 리소스를 요청할 수 있다. 이 경우는 스토리지에 대한 요청이다. 동일한 [리소스 모델](https://git.k8s.io/design-proposals-archive/scheduling/resources.md)이 볼륨과 클레임 모두에 적용된다. ### 셀렉터 @@ -1012,7 +1021,7 @@ PVC를 위한 적절한 파퓰레이터가 설치되어 있다면, * [퍼시스턴트볼륨 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨-생성하기)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#퍼시스턴트볼륨클레임-생성하기)에 대해 자세히 알아보기 -* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기 +* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md) 읽어보기 ### API 레퍼런스 {#reference} diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 970b7f3ddd..bb4a3494fb 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -1,9 +1,9 @@ --- - - - - - +## reviewers: +## - jsafrane +## - saad-ali +## - thockin +## - msau42 title: 스토리지 클래스 content_type: concept weight: 30 @@ -87,7 +87,7 @@ volumeBindingMode: Immediate 여기 목록에서 "내부" 프로비저너를 지정할 수 있다(이 이름은 "kubernetes.io" 가 접두사로 시작하고, 쿠버네티스와 함께 제공된다). 또한, 쿠버네티스에서 정의한 -[사양](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)을 +[사양](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md)을 따르는 독립적인 프로그램인 외부 프로비저너를 실행하고 지정할 수 있다. 외부 프로비저너의 작성자는 코드의 수명, 프로비저너의 배송 방법, 실행 방법, (Flex를 포함한)볼륨 플러그인 diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index c7f6a2df5a..a530b7b1f2 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -1,9 +1,9 @@ --- - - - - - +## reviewers: +## - jsafrane +## - saad-ali +## - thockin +## - msau42 title: 볼륨 content_type: concept weight: 10 @@ -64,7 +64,9 @@ weight: 10 쿠버네티스는 여러 유형의 볼륨을 지원한다. -### awsElasticBlockStore {#awselasticblockstore} +### awsElasticBlockStore (사용 중단됨) {#awselasticblockstore} + +{{< feature-state for_k8s_version="v1.17" state="deprecated" >}} `awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) [EBS 볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 @@ -135,7 +137,9 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} `azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다. @@ -158,7 +162,9 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} `azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에 마운트한다. @@ -201,7 +207,9 @@ CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다. -### cinder +### cinder (사용 중단됨) + +{{< feature-state for_k8s_version="v1.18" state="deprecated" >}} {{< note >}} 쿠버네티스는 오픈스택 클라우드 공급자로 구성되어야 한다. @@ -295,15 +303,17 @@ spec: ### downwardAPI {#downwardapi} -`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 한다. -이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다. +`downwardAPI` 볼륨은 애플리케이션에서 {{< glossary_tooltip term_id="downward-api" text="다운워드(downward) API" >}} +데이터를 사용할 수 있도록 한다. 볼륨 내에서 노출된 데이터를 +일반 텍스트 형식의 읽기 전용 파일로 찾을 수 있다. {{< note >}} 다운워드 API를 [`subPath`](#using-subpath) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다. {{< /note >}} -더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다. +더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +를 참고한다. ### emptyDir {#emptydir} @@ -390,7 +400,9 @@ Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이 더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다. -### gcePersistentDisk +### gcePersistentDisk (사용 중단됨) {#gcepersistentdisk} + +{{< feature-state for_k8s_version="v1.17" state="deprecated" >}} `gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진(GCE) [영구 디스크](https://cloud.google.com/compute/docs/disks)(PD)를 파드에 마운트한다. @@ -1146,7 +1158,7 @@ CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는 컨테이너 오케스트레이션 시스템(쿠버네티스와 같은)을 위한 표준 인터페이스를 정의하여 임의의 스토리지 시스템을 컨테이너 워크로드에 노출시킨다. -더 자세한 정보는 [CSI 디자인 제안](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)을 읽어본다. +더 자세한 정보는 [CSI 디자인 제안](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md)을 읽어본다. {{< note >}} CSI 규격 버전 0.2와 0.3에 대한 지원은 쿠버네티스 v1.13에서 사용중단(deprecated) @@ -1240,6 +1252,20 @@ CSI 설정 변경 없이 평소와 같이 CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. +#### 윈도우 CSI 프록시 + +{{< feature-state for_k8s_version="v1.22" state="stable" >}} + +CSI 노드 플러그인은 디스크 장치 검색 및 파일 시스템 마운트 같은 +다양한 권한이 부여된 작업을 수행해야 한다. 이러한 작업은 +호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우, 일반적으로 컨테이너형 +CSI 노드 플러그인은 권한 있는 컨테이너로 배포된다. 윈도우 워커 노드의 경우, +각 윈도우 노드에 미리 설치해야 하는 커뮤니티판 스탠드얼론(stand-alone) 바이너리인 +[csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 이용하여 +컨테이너형 CSI 노드 플러그인에 대한 권한 있는 작업을 지원한다. + +자세한 내용은 배포할 CSI 플러그인의 배포 가이드를 참고한다. + #### 인-트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 {{< feature-state for_k8s_version="v1.17" state="beta" >}} @@ -1256,6 +1282,14 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 `CSIMigration` 을 지원하고 해당 CSI 드라이버가 구현된 인-트리 플러그인은 [볼륨 유형들](#volume-types)에 나열되어 있다. +다음 인-트리 플러그인은 윈도우 노드에서 퍼시스턴트볼륨을 지원한다. + +* [`awsElasticBlockStore`](#awselasticblockstore) +* [`azureDisk`](#azuredisk) +* [`azureFile`](#azurefile) +* [`gcePersistentDisk`](#gcepersistentdisk) +* [`vsphereVolume`](#vspherevolume) + ### flexVolume {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} @@ -1267,6 +1301,12 @@ FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된 파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. 더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다. +호스트에 PowerShell 스크립트로 배포된 다음과 같은 +FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다. + +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) + {{< note >}} FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다. From a2b879b5b43dc6b21f53189a2b53e0997470a10b Mon Sep 17 00:00:00 2001 From: Nayeon Keum Date: Sat, 30 Jul 2022 17:34:20 +0900 Subject: [PATCH 042/202] [ko] Update outdated file: dev-1.24-ko.1(M84-M89) Signed-off-by: Nayeon Keum --- content/ko/docs/tasks/manage-daemon/update-daemon-set.md | 2 +- .../docs/tasks/run-application/force-delete-stateful-set-pod.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index d8c7aa935b..fa9cf00eb0 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -79,7 +79,7 @@ kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dr 두 명령의 출력 결과는 다음과 같아야 한다. -```shell +``` RollingUpdate ``` diff --git a/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md index c532b1b9a1..3bb3bf6a55 100644 --- a/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/ko/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -52,7 +52,7 @@ kubectl delete pods 사용자가 연결할 수 없는 노드에서 파드를 단계적으로 삭제하려고 하면 파드가 이러한 상태에 들어갈 수도 있다. 이러한 상태의 파드를 apiserver에서 제거할 수 있는 유일한 방법은 다음과 같다. -* 노드 오브젝트가 삭제된다(사용자 또는 [노드 컨트롤러](/ko/docs/concepts/architecture/nodes/)에 의해). +* 노드 오브젝트가 삭제된다(사용자 또는 [노드 컨트롤러](/ko/docs/concepts/architecture/nodes/#노드-컨트롤러)에 의해). * 응답하지 않는 노드의 kubelet이 응답을 시작하고 파드를 종료하여 apiserver에서 항목을 제거한다. * 사용자가 파드를 강제로 삭제한다. From f81fac31c8ca3f5cf188beec2633627ba395b4ff Mon Sep 17 00:00:00 2001 From: Wander P da Silva <55059282+wandpsilva@users.noreply.github.com> Date: Sun, 31 Jul 2022 16:17:10 -0300 Subject: [PATCH 043/202] fixing file name changing to lowercase --- content/pt-br/docs/reference/glossary/{Docker.md => docker.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/pt-br/docs/reference/glossary/{Docker.md => docker.md} (100%) diff --git a/content/pt-br/docs/reference/glossary/Docker.md b/content/pt-br/docs/reference/glossary/docker.md similarity index 100% rename from content/pt-br/docs/reference/glossary/Docker.md rename to content/pt-br/docs/reference/glossary/docker.md From 6f25a2fbbfa3eefcd0ae7816a073bd83102f7d6a Mon Sep 17 00:00:00 2001 From: Poison Date: Mon, 1 Aug 2022 10:52:28 +0800 Subject: [PATCH 044/202] Make the link text the same as the link title --- .../production-environment/tools/kubeadm/install-kubeadm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 993ecf3878..e5ab08a470 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -12,7 +12,7 @@ card: This page shows how to install the `kubeadm` toolbox. -For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. +For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. ## {{% heading "prerequisites" %}} From 39ada0009a179cdc57024c01e37e18eb85390177 Mon Sep 17 00:00:00 2001 From: onestone9900 Date: Tue, 26 Jul 2022 23:06:52 +0900 Subject: [PATCH 045/202] add content/ko/docs/reference/glossary/horizontal-pod-autoscaler.md --- .../glossary/horizontal-pod-autoscaler.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/ko/docs/reference/glossary/horizontal-pod-autoscaler.md diff --git a/content/ko/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/ko/docs/reference/glossary/horizontal-pod-autoscaler.md new file mode 100644 index 0000000000..00cde2b435 --- /dev/null +++ b/content/ko/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -0,0 +1,18 @@ +--- +title: Horizontal Pod Autoscaler +id: horizontal-pod-autoscaler +date: 2018-04-12 +full_link: /ko/docs/tasks/run-application/horizontal-pod-autoscale/ +short_description: > + CPU 사용률 또는 사용자 정의 메트릭을 기반으로 파드의 레플리카 수를 자동으로 조절하는 API 리소스이다. + +aka: +- HPA +tags: +- operation +--- + CPU 사용률 또는 사용자 정의 메트릭을 기반으로 {{< glossary_tooltip text="파드" term_id="pod" >}}의 레플리카 수를 자동으로 조절하는 API 리소스이다. + + + +HPA는 일반적으로 {{< glossary_tooltip text="레플리케이션 컨트롤러" term_id="replication-controller" >}}, {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}, {{< glossary_tooltip text="레플리카셋" term_id="replica-set" >}}과 함께 사용된다. 조절할 수 없는 개체(예: {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다. \ No newline at end of file From 6840b1c994ad1f91031c047d17ad1d36345788ad Mon Sep 17 00:00:00 2001 From: Yoon Seo-Yul Date: Mon, 25 Jul 2022 20:07:08 +0900 Subject: [PATCH 046/202] [ko] Translate the glossary term 'Dockershim' into Korean MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit [ko] Translate the glossary term 'Helm Chart' into Korean Apply suggestions from code review Co-authored-by: 송원석 [ko] Translate the glossary term 'HostAliases' into Korean Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> [ko] Translate the glossary term 'Kubeadm' into Korean Apply suggestions from code review kubeadm Co-authored-by: Tim Bannister Apply suggestions from code review Co-authored-by: Byung Woo LEE 안전한(secure) 영문 표기 병행 Apply suggestions from code review Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> --- .../ko/docs/reference/glossary/dockershim.md | 18 ++++++++++++++++++ .../ko/docs/reference/glossary/helm-chart.md | 19 +++++++++++++++++++ .../docs/reference/glossary/host-aliases.md | 17 +++++++++++++++++ content/ko/docs/reference/glossary/kubeadm.md | 19 +++++++++++++++++++ 4 files changed, 73 insertions(+) create mode 100644 content/ko/docs/reference/glossary/dockershim.md create mode 100644 content/ko/docs/reference/glossary/helm-chart.md create mode 100644 content/ko/docs/reference/glossary/host-aliases.md create mode 100644 content/ko/docs/reference/glossary/kubeadm.md diff --git a/content/ko/docs/reference/glossary/dockershim.md b/content/ko/docs/reference/glossary/dockershim.md new file mode 100644 index 0000000000..34226700f3 --- /dev/null +++ b/content/ko/docs/reference/glossary/dockershim.md @@ -0,0 +1,18 @@ +--- +title: 도커심(Dockershim) +id: dockershim +date: 2022-04-15 +full_link: /dockershim +short_description: > + 쿠버네티스 1.23 이하의 버전에서 쿠버네티스 시스템 구성 요소가 도커 엔진과 통신할 수 있게 해주는 컴포넌트 + +aka: +tags: +- fundamental +--- +도커심(Dockershim)은 쿠버네티스 버전 1.23 이하의 구성 요소이다. +kubelet이 {{< glossary_tooltip text="도커 엔진" term_id="docker" >}}과 통신할 수 있게 한다. + + + +1.24버전 부터 도커심(Dockershim)은 쿠버네티스에서 제거되었다. 자세한 사항은 [Dockershim FAQ](/dockershim)를 참고한다. diff --git a/content/ko/docs/reference/glossary/helm-chart.md b/content/ko/docs/reference/glossary/helm-chart.md new file mode 100644 index 0000000000..55ab2740f4 --- /dev/null +++ b/content/ko/docs/reference/glossary/helm-chart.md @@ -0,0 +1,19 @@ +--- +title: 헬름 차트(Helm Chart) +id: helm-chart +date: 2018-04-12 +full_link: https://helm.sh/ko/docs/topics/charts/ +short_description: > + 헬름(Helm) 도구를 통해 관리할 수 있는 사전 구성된 쿠버네티스 리소스 패키지 + +aka: +tags: +- tool +--- + 헬름(Helm) 도구를 통해 관리할 수 있는 사전 구성된 쿠버네티스 리소스 패키지 + + + +차트는 쿠버네티스 애플리케이션을 생성하고 공유하는 반복 가능한 방법을 제공한다. +단일 차트는 Memcached 파드와 같이 간단한 것부터 HTTP 서버, 데이터베이스, 캐시 등이 포함된 전체 웹 앱 스택과 같은 복잡한 것까지 배포하는 데 사용할 수 있다. + diff --git a/content/ko/docs/reference/glossary/host-aliases.md b/content/ko/docs/reference/glossary/host-aliases.md new file mode 100644 index 0000000000..f1580cb187 --- /dev/null +++ b/content/ko/docs/reference/glossary/host-aliases.md @@ -0,0 +1,17 @@ +--- +title: 호스트에일리어스(HostAlias) +id: HostAliases +date: 2019-01-31 +full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core +short_description: > + 호스트에일리어스는 파드의 hosts 파일에 주입될 IP 주소와 호스트네임간의 매핑이다. + +aka: +tags: +- operation +--- +호스트에일리어스는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 hosts 파일에 주입될 IP 주소와 호스트네임간의 매핑이다. + + + +[호스트에일리어스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core)은 명시된 경우에만 파드의 hosts 파일에 주입되는 호스트네임 및 IP 주소의 선택적 목록이다. 이는 hostNetwork 모드를 사용하고 있지 않은 파드에서만 유효하다. diff --git a/content/ko/docs/reference/glossary/kubeadm.md b/content/ko/docs/reference/glossary/kubeadm.md new file mode 100644 index 0000000000..4ed49657ae --- /dev/null +++ b/content/ko/docs/reference/glossary/kubeadm.md @@ -0,0 +1,19 @@ +--- +title: kubeadm +id: kubeadm +date: 2018-04-12 +full_link: /docs/admin/kubeadm/ +short_description: > + 쿠버네티스를 빠르게 설치하고 안전한(secure) 클러스터를 설정하는 도구 + +aka: +tags: +- tool +- operation +--- + 쿠버네티스를 빠르게 설치하고 안전한(secure) 클러스터를 설정하는 도구 + + + +kubeadm을 사용하여 컨트롤 플레인과 {{< glossary_tooltip text="워커 노드" term_id="node" >}} 구성 요소를 설치할 수 있다. + From 9f112763e62c9ff51ccd45591ce17cda11a2e36c Mon Sep 17 00:00:00 2001 From: Yoon Seo-Yul Date: Wed, 27 Jul 2022 22:22:01 +0900 Subject: [PATCH 047/202] [ko] Translate the docs/tasks/access-application-cluster 'create-external-load-balancer' into Korean Apply suggestions from code review Co-authored-by: Yoon --- .../create-external-load-balancer.md | 203 ++++++++++++++++++ 1 file changed, 203 insertions(+) create mode 100644 content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md diff --git a/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md new file mode 100644 index 0000000000..df2b1c89fc --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -0,0 +1,203 @@ +--- +title: 외부 로드 밸런서 생성하기 +content_type: task +weight: 80 +--- + + + +이 문서는 외부 로드 밸런서를 생성하는 방법에 관하여 설명한다. + +{{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 때, +클라우드 로드 밸런서를 자동으로 생성하는 옵션을 사용할 수 있다. +이것은 클러스터 노드의 올바른 포트로 트래픽을 전송할 수 있도록 +외부에서 접근 가능한 IP 주소를 제공한다. +_클러스터가 지원되는 환경과 +올바른 클라우드 로드 밸런서 제공자 패키지 구성으로 실행되는 경우._ + +또한, 서비스 대신 {{< glossary_tooltip text="인그레스(Ingress)" term_id="ingress" >}} 를 사용할 수 있다. +자세한 사항은 [인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress/) +문서를 참고한다. + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + +클러스터는 반드시 클라우드 또는 외부 로드 밸런서 구성을 지원하는 +환경에서 실행 중이어야 한다. + + + + +## 서비스 생성 + +### 매니페스트를 사용하여 서비스 생성하기 + +외부 로드 밸런서를 생성하기 위해서, 서비스 매니페스트에 +다음을 추가한다. + +```yaml + type: LoadBalancer +``` + +매니페스트는 아래와 같을 것이다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + type: LoadBalancer +``` + +### kubectl를 이용하여 서비스 생성하기 + +또한, `kubectl expose` 명령어에 `--type=LoadBalancer` 플래그를 이용해 +서비스를 생성할 수 있다. + +```bash +kubectl expose deployment example --port=8765 --target-port=9376 \ + --name=example-service --type=LoadBalancer +``` + +이 명령은 동일한 리소스를 셀렉터로 참조하는 새로운 서비스를 만든다. +(위 예시의 경우, `example`로 명명된 +{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}} ). + +명령줄 옵션 플래그를 포함한, 더 자세한 내용은 +[`kubectl expose` 레퍼런스](/ko/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다. + +## IP 주소 찾기 + +`kubectl` 명령어를 사용해 서비스 정보를 얻어, +생성된 서비스에 관한 IP 주소를 찾을 수 있다. + +```bash +kubectl describe services example-service +``` + +출력은 다음과 같다. + +``` +Name: example-service +Namespace: default +Labels: app=example +Annotations: +Selector: app=example +Type: LoadBalancer +IP Families: +IP: 10.3.22.96 +IPs: 10.3.22.96 +LoadBalancer Ingress: 192.0.2.89 +Port: 8765/TCP +TargetPort: 9376/TCP +NodePort: 30593/TCP +Endpoints: 172.17.0.3:9376 +Session Affinity: None +External Traffic Policy: Cluster +Events: +``` + +로드 밸런서의 IP 주소는 `LoadBalancer Ingress` 옆에 나타난다. + +{{< note >}} +만약 서비스가 Minikube에서 실행되고 있다면, 아래의 명령을 통해 할당된 IP 주소와 포트를 찾을 수 있다. + +```bash +minikube service example-service --url +``` +{{< /note >}} + +## 클라이언트 소스 IP 보존하기 {#preserving-the-client-source-ip} + +기본적으로 대상 컨테이너에 보이는 소스 IP는 클라이언트의 *원래 소스 IP가 아니다.* +클라이언트의 IP를 보존할 수 있도록 하려면, +아래의 서비스 `.spec` 필드 구성을 따른다. + +* `.spec.externalTrafficPolicy` - 이 서비스가 외부 트래픽을 노드-로컬 또는 + 클러스터-전체 엔드포인트로 라우팅할지 여부를 나타낸다. + 두 가지 옵션이 있다. `Cluster` (기본) 그리고 `Local`. + `Cluster` 는 클라이언트 소스 IP를 가리고 다른 노드에 대한 + 두 번째 홉(hop)을 발생시킬 수 있지만, + 전체적인 부하 분산에서 이점이 있다. + `Local` 은 클라이언트 소스 IP를 보존하고 + `LoadBalancer`와 `NodePort` 타입의 서비스에서 두 번째 홉(hop) 발생을 피할 수 있지만, + 트래픽 분산이 불균형적인 잠재적인 위험이 있다. +* `.spec.healthCheckNodePort` - 서비스를 위한 헬스 체크 노드 포트(정수 포트 번호)를 지정한다. + `healthCheckNodePort`를 지정하지 않으면, + 서비스 컨트롤러가 클러스터의 노트 포트 범위에서 포트를 할당한다. + API 서버 명령줄 플래그 `--service-node-port-range`를 설정하여 해당 범위를 구성할 수 있다. + 서비스 `type`이 `LoadBalancer`이고 `externalTrafficPolicy`를 `Local`로 설정한 경우, + 서비스는 `healthCheckNodePort`가 지정되었다면, + 사용자가 지정한 설정을 이용한다. + +서비스 매니페스트에서 `externalTrafficPolicy`를 `Local`로 설정하면 이 기능이 작동한다. +예시: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: example-service +spec: + selector: + app: example + ports: + - port: 8765 + targetPort: 9376 + externalTrafficPolicy: Local + type: LoadBalancer +``` + +### 소스 IP를 보존할 때 주의사항 및 제한 사항 {#caveats-and-limitations-when-preserving-source-ips} + +일부 클라우드 제공자의 로드 밸런싱 서비스에서는 대상별로 다른 가중치를 구성할 수 없다. + +각 대상의 가중치는 노드로 전송하는 트래픽을 측면에서 균등하게 부여하기 때문에 +외부 트래픽은 서로 다른 파드 간에 로드 밸런싱되지 않는다. +외부 로드 밸런서는 각 노드에서 대상으로 사용되는 파드의 개수를 인식하지 못한다. + +`서비스파드개수 << 노드개수` 이거나 `서비스파드개수 >> 노드개수` 인 경우에선 +가중치 없이도 거의 균등한 분포를 볼 수 있다. + +내부 파드 간 트래픽은 `ClusterIP` 서비스에서와 비슷하게 모든 파드에서 동일한 확률로 IP 서비스를 제공한다. + +## 가비지(Garbage) 수집 로드 밸런서 {#garbage-collecting-load-balancers} + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + +일반적으로 클라우드 제공자와 관련 있는 로드밸런서 리소스는 `type`이 `LoadBalancer`인 +서비스가 삭제된 후 즉시 정리되어야 한다. +그러나 관련 서비스가 삭제된 후 클라우드 리소스가 고아가 되는 코너 케이스가 다양한 것으로 알려져 있다. +이러한 문제를 예방하기 위해 서비스 로드밸런서를 위한 `Finalizer Protection`이 도입되었다. +`Finalizer`를 사용하면, 서비스 리소스는 로드밸런서 관련 리소스가 삭제될 때까지 삭제되지 않는다. + +특히 서비스에 `type`이 `LoadBalancer`인 경우 +서비스 컨트롤러는 `service.kubernetes.io/load-balancer-cleanup` +이라는 이름의 `finalizer`를 붙인다. +`finalizer`는 (클라우드) 로드 밸런서 리소스를 정리한 후에만 제거된다. +이렇게 하면 서비스 컨트롤러 충돌(crash)과 같은 코너 케이스에서도 +로드 밸런서 리소스가 고아가 되는 것을 방지할 수 있다. + +## 외부 로드 밸런서 제공자 {#external-load-balancer-providers} + +중요한 점은 이 기능을 위한 데이터 경로는 쿠버네티스 클러스터 외부의 로드 밸런서에서 제공한다는 것이다. + +서비스의 `type`이 `LoadBalancer`로 설정된 경우, +쿠버네티스는 `type`이 `ClusterIP`인 경우처럼 동등한 기능을 클러스터 내의 파드에 제공하고 +관련 쿠버네티스 파드를 호스팅하는 노드에 대한 항목으로 (쿠버네티스 외부) 로드 밸런서를 프로그래밍을 통해 확장한다. +쿠버네티스 컨트롤 플레인은 외부 로드 밸런서, (필요한 경우) 헬스 체크 및 (필요한 경우) 패킷 필터링 규칙의 생성을 자동화한다. +클라우드 공급자가 로드 밸런서에 대한 IP 주소를 할당하면 컨트롤 플레인이 해당 외부 IP 주소를 찾아 서비스 오브젝트를 갱신한다. + +## {{% heading "whatsnext" %}} + +* [서비스](/ko/docs/concepts/services-networking/service/)에 대해 알아보기 +* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 From 671ee563cd220fb0860641d035e898c9a603241f Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Thu, 28 Jul 2022 08:58:34 +0900 Subject: [PATCH 048/202] [ko] Translate the glossary term "SIG" --- content/ko/docs/reference/glossary/sig.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 content/ko/docs/reference/glossary/sig.md diff --git a/content/ko/docs/reference/glossary/sig.md b/content/ko/docs/reference/glossary/sig.md new file mode 100644 index 0000000000..fbd6a3c86b --- /dev/null +++ b/content/ko/docs/reference/glossary/sig.md @@ -0,0 +1,21 @@ +--- +title: SIG(special interest group) +id: sig +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups +short_description: > + 대규모 쿠버네티스 오픈소스 프로젝트에서 진행되는 내용을 공동으로 관리하는 커뮤니티 멤버들이다. + +aka: +tags: +- community +--- + 대규모 쿠버네티스 오픈소스 프로젝트에서 진행되는 내용을 공동으로 관리하는 커뮤니티 {{< glossary_tooltip text="멤버" term_id="member" >}}들이다. + + + +SIG 멤버들은 아키텍처, API, 또는 문서화 같이 특정 영역을 발전시키는 데 공통적으로 관심을 갖고 있다. +기본적으로 SIG [거버넌스 지침](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md)을 따라야 하지만, 자체적으로 기여 정책이나 소통 채널을 가질 수 있다. + +자세한 내용은 [kubernetes/community](https://github.com/kubernetes/community) 저장소 및 현재 존재하는 [SIG 및 WG](https://github.com/kubernetes/community/blob/master/sig-list.md) 목록을 참조한다. + From aa4c446e70b8f7f72e04b38c53ec78f354c552dc Mon Sep 17 00:00:00 2001 From: KimDoubleB Date: Mon, 25 Jul 2022 19:47:35 +0900 Subject: [PATCH 049/202] [ko] Translate the glossary term 'Code Contributor' into Korean --- .../reference/glossary/code-contributor.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 content/ko/docs/reference/glossary/code-contributor.md diff --git a/content/ko/docs/reference/glossary/code-contributor.md b/content/ko/docs/reference/glossary/code-contributor.md new file mode 100644 index 0000000000..7ef546a578 --- /dev/null +++ b/content/ko/docs/reference/glossary/code-contributor.md @@ -0,0 +1,19 @@ +--- +title: 코드 컨트리뷰터(Code Contributor) +id: code-contributor +date: 2018-04-12 +full_link: /ko/docs/community/devel/ +short_description: > + 쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람. + +aka: +tags: +- community +- user-type +--- + 쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람. + + + +그들은 하나 이상의 {{< glossary_tooltip text="Special Interest Group (SIG)" term_id="sig" >}}에 참여하는 활동적인 {{< glossary_tooltip text="커뮤니티 멤버" term_id="member" >}}이기도 하다. + From abd61c787d8bab7f38d1fcfcf1af46ecae82107d Mon Sep 17 00:00:00 2001 From: cat-taesik Date: Thu, 28 Jul 2022 20:06:45 +0900 Subject: [PATCH 050/202] Translate the glossary term Disruption into Korean Signed-off-by: cat-taesik Co-authored-by: Sanghong Kim <58922834+bconfiden2@users.noreply.github.com> Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> --- .../ko/docs/reference/glossary/disruption.md | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 content/ko/docs/reference/glossary/disruption.md diff --git a/content/ko/docs/reference/glossary/disruption.md b/content/ko/docs/reference/glossary/disruption.md new file mode 100644 index 0000000000..b1dd929de8 --- /dev/null +++ b/content/ko/docs/reference/glossary/disruption.md @@ -0,0 +1,25 @@ +--- +title: 중단(Disruption) +id: disruption +date: 2019-09-10 +full_link: /ko/docs/concepts/workloads/pods/disruptions/ +short_description: > + 파드의 서비스 중단으로 이어지는 이벤트 +aka: +tags: +- fundamental +--- +중단은 하나 이상의 {{< glossary_tooltip term_id="pod" text="파드" >}}를 +중단시키게 만드는 이벤트를 의미한다. +중단은 {{< glossary_tooltip term_id="deployment" >}}와 같이 +해당 영향을 받는 파드에 의존하는 워크로드 리소스에도 영향을 +준다. + + + +클러스터 오퍼레이터로서, 애플리케이션에 속한 파드를 직접 파괴하는 경우 +쿠버네티스는 이를 _자발적 중단(voluntary disruption)_ 이라고 칭한다. +노드 장애 또는 더 넓은 영역에 장애를 일으키는 정전 등으로 인해 파드가 오프라인 상태가 되면 +쿠버네티스는 이를 _비자발적 중단(involuntary disruption)_ 이라고 한다. + +자세한 정보는 [중단](/ko/docs/concepts/workloads/pods/disruptions/)을 확인한다. From 4747731407abc513e8eb4f79c71e5a9f19dfe83c Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Fri, 29 Jul 2022 17:57:38 -0700 Subject: [PATCH 051/202] Fix --service-account-key-file description --service-account-key-file flag to the kube-api-server is used to verify ServiceAccount tokens (and not to sign them). --service-account-signing-key-file is the kube-api-server flag that's used to sign ServiceAccount tokens (short-lived ones). --service-account-private-key-file is the kube-controller-manager flag that's used to sign ServiceAccount tokens (long-lived ones). --- .../en/docs/reference/access-authn-authz/authentication.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/authentication.md b/content/en/docs/reference/access-authn-authz/authentication.md index 1641cb8e54..176ffd2ecb 100644 --- a/content/en/docs/reference/access-authn-authz/authentication.md +++ b/content/en/docs/reference/access-authn-authz/authentication.md @@ -171,8 +171,10 @@ how to manage these tokens with `kubeadm`. A service account is an automatically enabled authenticator that uses signed bearer tokens to verify requests. The plugin takes two optional flags: -* `--service-account-key-file` A file containing a PEM encoded key for signing bearer tokens. -If unspecified, the API server's TLS private key will be used. +* `--service-account-key-file` File containing PEM-encoded x509 RSA or ECDSA +private or public keys, used to verify ServiceAccount tokens. The specified file +can contain multiple keys, and the flag can be specified multiple times with +different files. If unspecified, --tls-private-key-file is used. * `--service-account-lookup` If enabled, tokens which are deleted from the API will be revoked. Service accounts are usually created automatically by the API server and From b1a5f31dd518f6d2e6feb3e41128a678230cdcd6 Mon Sep 17 00:00:00 2001 From: Rohit Agarwal Date: Thu, 14 Apr 2022 14:47:09 -0700 Subject: [PATCH 052/202] Remove unnecessary step to manually update the service account secrets Playing with v1.19.16, it seems that updating `--root-ca-file` flag in the kube-controller-manager config and then restart it results in all those Secrets getting updated with the new value. --- .../tls/manual-rotation-of-ca-certificates.md | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index bad390575d..2de01325f9 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -51,23 +51,11 @@ Configurations with a single API server will experience unavailability while the kube-controller-manager being unable to accept a CA bundle. {{< /note >}} -1. Update all Secrets that hold service account tokens to include both old and new CA certificates. +1. Wait for the controller manager to update `ca.crt` in the service account Secrets to include both old and new CA certificates. If any Pods are started before new CA is used by API servers, the new Pods get this update and will trust both old and new CAs. - ```shell - base64_encoded_ca="$(base64 -w0 )" - - for namespace in $(kubectl get namespace --no-headers -o name | cut -d / -f 2 ); do - for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do - kubectl get $token --namespace "$namespace" -o yaml | \ - /bin/sed "s/\(ca.crt:\).*/\1 ${base64_encoded_ca}/" | \ - kubectl apply -f - - done - done - ``` - 1. Restart all pods using in-cluster configurations (for example: kube-proxy, CoreDNS, etc) so they can use the updated certificate authority data from Secrets that link to ServiceAccounts. From 9a4597563cb937f5f1f154fe440889d97208aa77 Mon Sep 17 00:00:00 2001 From: Shubham Kuchhal Date: Tue, 2 Aug 2022 17:28:47 +0530 Subject: [PATCH 053/202] Updated the Feature state of Serving and Terminating. --- .../en/docs/concepts/services-networking/endpoint-slices.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index cd90ecdcfd..fc97ef04a5 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/content/en/docs/concepts/services-networking/endpoint-slices.md @@ -108,7 +108,7 @@ Services will always have the `ready` condition set to `true`. #### Serving -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} `serving` is identical to the `ready` condition, except it does not account for terminating states. Consumers of the EndpointSlice API should check this condition if they care about pod readiness while @@ -127,7 +127,7 @@ for terminating pods independent of the existing semantics for `ready`. #### Terminating -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} `Terminating` is a condition that indicates whether an endpoint is terminating. For pods, this is any pod that has a deletion timestamp set. From ccd241543c18ebc995e9776cd15dab62721eb02e Mon Sep 17 00:00:00 2001 From: Byung Woo LEE Date: Tue, 2 Aug 2022 22:38:54 +0900 Subject: [PATCH 054/202] [ko] Translate the glossary term 'CIDR' into Korean --- content/ko/docs/reference/glossary/cidr.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 content/ko/docs/reference/glossary/cidr.md diff --git a/content/ko/docs/reference/glossary/cidr.md b/content/ko/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000..fb9dc658c9 --- /dev/null +++ b/content/ko/docs/reference/glossary/cidr.md @@ -0,0 +1,19 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR은 IP 주소 블록을 설명하는 표기법으로 다양한 네트워킹 구성에서 많이 사용한다. + +aka: +tags: +- networking +--- +CIDR (Classless Inter-Domain Routing)은 IP 주소 블록을 설명하는 표기법으로 다양한 네트워킹 구성에서 많이 사용한다. + + + +쿠버네티스에서는 CIDR을 사용하여 시작 주소와 서브넷 마스크로 각 {{< glossary_tooltip text="노드" term_id="node" >}}에 IP 주소 범위를 할당한다. +이를 통해 노드는 각 {{< glossary_tooltip text="파드" term_id="pod" >}}에 고유한 IP 주소를 할당할 수 있다. 원래 IPv4를 위한 개념이었지만 CIDR은 IPv6도 포함하도록 확장됐다. + From 19f00379baed9dc079f2d717dd161ababad7bb34 Mon Sep 17 00:00:00 2001 From: Yoon Date: Tue, 2 Aug 2022 22:17:39 +0900 Subject: [PATCH 055/202] Add yoonian to ko-owners --- OWNERS_ALIASES | 1 + 1 file changed, 1 insertion(+) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 443410ae56..f502aaf113 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -136,6 +136,7 @@ aliases: - ianychoi - jihoon-seo - seokho-son + - yoonian - ysyukr sig-docs-ko-reviews: # PR reviews for Korean content - ClaudiaJKang From 1b598b3f551981f937215afc17f29e398dcb07a6 Mon Sep 17 00:00:00 2001 From: Kid-Chang Date: Wed, 3 Aug 2022 01:06:35 +0900 Subject: [PATCH 056/202] [ko] translate glossary wg(working group) --- content/ko/docs/reference/glossary/wg.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 content/ko/docs/reference/glossary/wg.md diff --git a/content/ko/docs/reference/glossary/wg.md b/content/ko/docs/reference/glossary/wg.md new file mode 100644 index 0000000000..ac9d122e3d --- /dev/null +++ b/content/ko/docs/reference/glossary/wg.md @@ -0,0 +1,20 @@ +--- +title: WG(working group) +id: wg +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list +short_description: > + 위원회(committee), SIG 내, 또는 SIG 간 노력을 위한 단기적이거나, 좁은 범위를 다루거나, 혹은 서로 연관되지 않은 프로젝트의 토론 및/또는 구현을 촉진한다. + +aka: +tags: + - community +--- + +위원회(committee), {{< glossary_tooltip text="SIG" term_id="sig" >}} 내, 또는 SIG 간 노력을 위한 단기적이거나, 좁은 범위를 다루거나, 혹은 서로 연관되지 않은 프로젝트의 토론 및 구현을 촉진한다. + + + +WG은 별개의 작업을 수행하기 위해 사람들을 조직하는 한 방법이다. + +자세한 내용은 [kubernetes/community](https://github.com/kubernetes/community) 저장소 및 현재 존재하는 [SIG 및 WG](https://github.com/kubernetes/community/blob/master/sig-list.md) 목록을 참조한다. From a26ae2f4fbadcc496765081dfc0aec19e3af7d13 Mon Sep 17 00:00:00 2001 From: kyungjin99 Date: Wed, 27 Jul 2022 20:58:40 +0900 Subject: [PATCH 057/202] [ko] Translate the glossary term 'CNCF' --- content/ko/docs/reference/glossary/cncf.md | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 content/ko/docs/reference/glossary/cncf.md diff --git a/content/ko/docs/reference/glossary/cncf.md b/content/ko/docs/reference/glossary/cncf.md new file mode 100644 index 0000000000..0cb9469066 --- /dev/null +++ b/content/ko/docs/reference/glossary/cncf.md @@ -0,0 +1,23 @@ +--- +title: 클라우드 네이티브 컴퓨팅 재단(CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + 클라우드 네이티브 컴퓨팅 재단 + +aka: +tags: +- community +--- + 클라우드 네이티브 컴퓨팅 재단(CNCF)은 지속 가능한 생태계를 구축하고 + 컨테이너를 마이크로서비스 아키텍처의 일부로 오케스트레이션 하는 [프로젝트](https://www.cncf.io/projects/) + 를 중심으로 커뮤니티를 조성한다. + +쿠버네티스는 CNCF 프로젝트이다. + + + +CNCF는 [리눅스 재단]((https://www.linuxfoundation.org/))의 산하 기구이다. +CNCF의 목표는 어디서나 클라우드 네이티브 컴퓨팅을 활용할 수 있도록 만드는 것이다. + From da39cd1405952c8c8d0edfb0991074a5879f36c8 Mon Sep 17 00:00:00 2001 From: Vaibhav Date: Wed, 3 Aug 2022 21:46:41 +0530 Subject: [PATCH 058/202] Updated the health checking link --- .../docs/reference/kubernetes-api/workload-resources/pod-v1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md index d26dfdbaf9..ef232320c8 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md @@ -1773,7 +1773,7 @@ Probe describes a health check to be performed against a container to determine - **grpc.service** (string) - Service is the name of the service to place in the gRPC HealthCheckRequest (see https://github.com/grpc/grpc/blob/master/doc/health-checking.md). + Service is the name of the service to place in the gRPC HealthCheckRequest (see https://github.com/grpc/grpc/blob/master/doc/health-checking.md ). If this is not specified, the default behavior is defined by gRPC. From 6658781099586466d43f9545431fc4b9b2c19335 Mon Sep 17 00:00:00 2001 From: Kinzhi Date: Sun, 31 Jul 2022 03:26:18 +0800 Subject: [PATCH 059/202] [zh-cn]Update content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md [zh-cn]Update content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md --- .../docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 64cf1c8acf..0f9c50d2f6 100644 --- a/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -17,12 +17,12 @@ weight: 20 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions -when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). +when upgrading is unsupported. For more details, please visit [Version Skew Policy](/releases/version-skew-policy/). --> 本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 {{< skew currentVersionAddMinor -1 >}}.x 版本 升级到 {{< skew currentVersion >}}.x 版本以及从 {{< skew currentVersion >}}.x 升级到 {{< skew currentVersion >}}.y（其中 `y > x`）。略过次版本号的升级是 -不被支持的。更多详情请访问[版本倾斜政策](https://kubernetes.io/releases/version-skew-policy/)。 +不被支持的。更多详情请访问[版本偏差策略](/zh-cn/releases/version-skew-policy/)。 @@ -164,7 +165,27 @@ API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 - 요청이 어드미션 제어 모듈(들)에 의해 처리된다. - 인증 및 인가 모듈을 실행한다. -GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면 -API 서버는 포트 443에서 서비스한다. -GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다. -이외에 클러스터 설정 방법은 다양하다. +## {{% heading "whatsnext" %}} + +인증 및 인가 그리고 API 접근 제어에 대한 추가적인 문서는 아래에서 찾을 수 있다. + +- [인증하기](/docs/reference/access-authn-authz/authentication/) + - [부트스트랩 토큰(bootstrap token)으로 인증하기](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [어드미션 컨트롤러(admission controller)](/docs/reference/access-authn-authz/admission-controllers/) + - [동적 어드미션(admission) 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [인가](/ko/docs/reference/access-authn-authz/authorization/) + - [역할 기반 접근 제어(role based access control)](/docs/reference/access-authn-authz/rbac/) + - [속성 기반 접근 제어(attribute based access control)](/docs/reference/access-authn-authz/abac/) + - [노드 인가](/docs/reference/access-authn-authz/node/) + - [웹훅(webhook) 인가](/docs/reference/access-authn-authz/webhook/) +- [인증서 서명 요청(Certificate Signing Request)](/docs/reference/access-authn-authz/certificate-signing-requests/) + - [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) 및 + [인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) 포함하기 +- 서비스 어카운트 + - [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/) + - [운영](/ko/docs/reference/access-authn-authz/service-accounts-admin/) + +또한, 다음 사항을 익힐 수 있다. +- 파드가 API 크리덴셜(credential)을 얻기 위해 + [시크릿(Secret)](/ko/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) + 을 사용하는 방법. diff --git a/content/ko/docs/concepts/services-networking/_index.md b/content/ko/docs/concepts/services-networking/_index.md index b80c3a40f6..2ebb1a0b4a 100644 --- a/content/ko/docs/concepts/services-networking/_index.md +++ b/content/ko/docs/concepts/services-networking/_index.md @@ -7,26 +7,25 @@ description: > ## 쿠버네티스 네트워크 모델 -모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. +클러스터의 모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며 또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 이로 인해 포트 할당, 네이밍, 서비스 디스커버리, [로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing), -애플리케이션 구성, 마이그레이션 관점에서 `파드`를 -VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다. +애플리케이션 구성, 마이그레이션 관점에서 `파드`를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 +하위 호환성을 갖는 모델이 제시된다. -쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다 -(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다) +쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다. +(이를 통해, 의도적인 네트워크 분할 정책을 방지) - * [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다 - * 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든 - 파드와 통신할 수 있다 + * 파드는 NAT 없이 [노드](/ko/docs/concepts/architecture/nodes/) 상의 모든 파드와 + 통신할 수 있다. + * 노드 상의 에이전트(예: 시스템 데몬, kubelet)는 해당 노드의 모든 + 파드와 통신할 수 있다. -참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는 -다음의 요구사항도 존재한다. - - * 한 노드의 호스트 네트워크에 있는 파드는 - NAT 없이 모든 노드의 모든 파드와 통신할 수 있다 +참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: +리눅스)에 대해서는, 파드가 노드의 호스트 네트워크에 연결되어 있을 때에도 파드는 여전히 +NAT 없이 모든 노드의 모든 파드와 통신할 수 있다. 이 모델은 전반적으로 덜 복잡할 뿐만 아니라, 무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. 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 9b4521e2b7..59ed5efc57 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -1,7 +1,7 @@ --- - - - +# reviewers: +# - davidopp +# - thockin title: 서비스 및 파드용 DNS content_type: concept weight: 20 @@ -226,6 +226,7 @@ DNS 정책은 파드별로 설정할 수 있다. 확인할 수 있다. - "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. + - 참고: 윈도우에서는 지원되지 않는다.상세 정보는 [아래](#dns-windows)에서 확인한다. - "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. 아래 절인 [파드의 DNS 설정](#pod-dns-config)에서 @@ -306,7 +307,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같 kubectl exec -it dns-example -- cat /etc/resolv.conf ``` 출력은 다음과 같은 형식일 것이다. -```shell +``` nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example options ndots:5 @@ -323,6 +324,24 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화 쿠버네티스는 최대 32개의 탐색 도메인과 최대 2048자의 탐색 도메인 목록을 허용한다. +## 윈도우 노드에서 DNS 해석(resolution) {#dns-windows} + +- ClusterFirstWithHostNet은 윈도우 노드에서 구동 중인 파드에는 지원되지 않는다. + 윈도우는 `.`를 포함한 모든 네임(주소)을 FQDN으로 취급하여 FQDN 해석을 생략한다. +- 윈도우에는 여러 DNS 해석기가 사용될 수 있다. 이러한 해석기는 + 각자 조금씩 다르게 동작하므로, 네임 쿼리 해석을 위해서 + [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname) + 파워쉘(powershell) cmdlet을 사용하는 것을 추천한다. +- 리눅스에는 DNS 접미사 목록이 있는데, 이는 네임이 완전한 주소가 아니어서 주소 + 해석에 실패한 경우 사용한다. + 윈도우에서는 파드의 네임스페이스(예: `mydns.svc.cluster.local`)와 연계된 + 하나의 DNS 접미사만 가질 수 있다. 윈도우는 이러한 단일 접미사 통해 해석될 수 있는 + FQDNs, 서비스, 또는 네트워크 네임을 해석할 수 있다. 예를 들어, `default`에 + 소속된 파드는 DNS 접미사 `default.svc.cluster.local`를 가진다. + 윈도우 파드 내부에서는 `kubernetes.default.svc.cluster.local`와 + `kubernetes`를 모두 해석할 수 있다. 그러나, 일부에만 해당(partially qualified)하는 네임(`kubernetes.default` 또는 + `kubernetes.default.svc`)은 해석할 수 없다. + ## {{% 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 1e8c9c2a03..276f2b5059 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -1,16 +1,15 @@ --- - - - - - title: IPv4/IPv6 이중 스택 feature: title: IPv4/IPv6 이중 스택 description: > 파드와 서비스에 IPv4와 IPv6 주소 할당 - content_type: concept +# reviewers: +# - lachie83 +# - khenidak +# - aramase +# - bridgetkromhout weight: 70 --- @@ -18,11 +17,11 @@ weight: 70 {{< feature-state for_k8s_version="v1.23" state="stable" >}} -IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. - -IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다. - +IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 +{{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. +IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 +활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다. @@ -38,60 +37,70 @@ IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터 IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음의 필수 구성 요소가 필요하다. - * 쿠버네티스 1.20 이상 - 이전 버전과 함께 이중 스택 서비스를 사용하는 방법에 대한 정보 - 쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 - 문서 참조 - * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) - * 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +* 쿠버네티스 1.20 및 이후 버전 + + 예전 버전 쿠버네티스에서 이중 스택 서비스를 사용하는 + 방법에 대한 정보는 해당 버전의 쿠버네티스에 대한 + 문서를 참조한다. + +* 이중 스택 네트워킹을 위한 공급자의 지원. (클라우드 공급자 또는 다른 방식으로 + 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 함.) +* 이중 스택 네트워킹을 지원하는 + [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). ## IPv4/IPv6 이중 스택 구성 IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. - * kube-apiserver: - * `--service-cluster-ip-range=,` - * kube-controller-manager: - * `--cluster-cidr=,` - * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. - * kube-proxy: - * `--cluster-cidr=,` - * kubelet: - * `--cloud-provider`가 명시되지 않았다면 - 관리자는 해당 노드에 듀얼 스택 `.status.addresses`를 수동으로 설정하기 위해 - 쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다. - 해당 노드의 파드가 HostNetwork 모드로 실행된다면, - 파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다. - 노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된 - IP 패밀리 선호사항을 만족한다. +* kube-apiserver: + * `--service-cluster-ip-range=,` +* kube-controller-manager: + * `--cluster-cidr=,` + * `--service-cluster-ip-range=,` + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. +* kube-proxy: + * `--cluster-cidr=,` +* kubelet: + * `--cloud-provider`가 명시되지 않았다면 관리자는 해당 노드에 듀얼 스택 + `.status.addresses`를 수동으로 설정하기 위해 쉼표로 구분된 IP 주소 쌍을 `--node-ip` 플래그로 전달할 수 있다. + 해당 노드의 파드가 HostNetwork 모드로 실행된다면, + 파드는 이 IP 주소들을 자신의 `.status.podIPs` 필드에 보고한다. + 노드의 모든 `podIPs`는 해당 노드의 `.status.addresses` 필드에 의해 정의된 + IP 패밀리 선호사항을 만족한다. {{< note >}} IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도) -IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) - +IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 +주소는 아니다. [RFC 4193](https://tools.ietf.org/html/rfc4193)을 확인한다.) {{< /note >}} ## 서비스 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다. -서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성) +서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. +(`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성) 서비스를 정의할 때 선택적으로 이중 스택으로 구성할 수 있다. 원하는 동작을 지정하려면 `.spec.ipFamilyPolicy` 필드를 다음 값 중 하나로 설정한다. -* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. +* `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 +클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `PreferDualStack`: * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. - * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. + * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 + `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. -단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다. +단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 +순서를 정의하려는 경우, 서비스에서 옵션 필드 +`.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다. {{< note >}} -`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 서비스를 삭제하고 다시 생성한다. +`.spec.ipFamilies` 필드는 이미 존재하는 서비스에 `.spec.ClusterIP`를 +재할당할 수 없기 때문에 변경할 수 없다. `.spec.ipFamilies`를 변경하려면 +서비스를 삭제하고 다시 생성한다. {{< /note >}} `.spec.ipFamilies`를 다음 배열 값 중 하나로 설정할 수 있다. @@ -109,139 +118,196 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 #### 새로운 서비스에 대한 이중 스택 옵션 -1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. 이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 `SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 같은 방식으로 동작한다.) +1. 이 서비스 사양은 `.spec.ipFamilyPolicy`를 명시적으로 정의하지 않는다. +이 서비스를 만들 때 쿠버네티스는 처음 구성된 `service-cluster-ip-range`에서 +서비스에 대한 클러스터 IP를 할당하고 `.spec.ipFamilyPolicy`를 +`SingleStack`으로 설정한다. ([셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)와 +같은 방식으로 동작한다.) {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} -1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 `.spec.ClusterIPs`에서 계산된 보조 필드이다. +1. 이 서비스 사양은 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 + 명시적으로 정의한다. 이중 스택 클러스터에서 이 서비스를 생성하면 쿠버네티스는 + 서비스에 대해 IPv4 및 IPv6 주소를 모두 할당한다. 컨트롤 플레인은 서비스의 + `.spec`을 업데이트하여 IP 주소 할당을 기록한다. 필드 `.spec.ClusterIPs`는 + 기본 필드이며 할당된 IP 주소를 모두 포함한다. `.spec.ClusterIP`는 값이 + `.spec.ClusterIPs`에서 계산된 보조 필드이다. - * `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP 범위와 동일한 주소 계열의 IP 주소를 기록한다. - * 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 모두 하나의 주소만 나열한다. - * 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 지정하면 `PreferDualStack`과 동일하게 작동한다. + * `.spec.ClusterIP` 필드의 경우 컨트롤 플레인은 첫 번째 서비스 클러스터 IP + 범위와 동일한 주소 계열의 IP 주소를 기록한다. + * 단일 스택 클러스터에서 `.spec.ClusterIPs` 및 `.spec.ClusterIP` 필드는 + 모두 하나의 주소만 나열한다. + * 이중 스택이 활성화된 클러스터에서 `.spec.ipFamilyPolicy`에 `RequireDualStack`을 + 지정하면 `PreferDualStack`과 동일하게 작동한다. {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} -1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다. +1. 이 서비스 사양은 `.spec.ipFamilies`에` IPv6`과 `IPv4`를 명시적으로 정의하고 + `.spec.ipFamilyPolicy`에 `PreferDualStack`을 정의한다. 쿠버네티스가 `.spec.ClusterIPs`에 + IPv6 및 IPv4 주소를 할당할 때 `.spec.ClusterIP`는 `.spec.ClusterIPs` 배열의 + 첫 번째 요소이므로 IPv6 주소로 설정되어 기본값을 재정의한다. {{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}} #### 기존 서비스의 이중 스택 기본값 -이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.) +이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 +경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 +이중 스택이 활성화된다.) -1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. +1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 + `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 + `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. + 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. -{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} kubectl을 사용하여 기존 서비스를 검사하여 이 동작을 검증할 수 있다. -```shell -kubectl get svc my-service -o yaml -``` + ```shell + kubectl get svc my-service -o yaml + ``` -```yaml -apiVersion: v1 -kind: Service -metadata: - labels: - app: MyApp - name: my-service -spec: - clusterIP: 10.0.197.123 - clusterIPs: - - 10.0.197.123 - ipFamilies: - - IPv4 - ipFamilyPolicy: SingleStack - ports: - - port: 80 - protocol: TCP - targetPort: 80 - selector: - app: MyApp - type: ClusterIP -status: - loadBalancer: {} -``` + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app: MyApp + name: my-service + spec: + clusterIP: 10.0.197.123 + clusterIPs: + - 10.0.197.123 + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app: MyApp + type: ClusterIP + status: + loadBalancer: {} + ``` -1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 지정한다. +1. 클러스터에서 이중 스택이 활성화된 경우, 셀렉터가 있는 기존 + [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)는 + `.spec.ClusterIP`가 `None`이라도 컨트롤 플레인이 `.spec.ipFamilyPolicy`을 + `SingleStack`으로 지정하고 `.spec.ipFamilies`는 첫 번째 서비스 + 클러스터 IP 범위(kube-apiserver에 대한 `--service-cluster-ip-range` 플래그를 통해 구성)의 주소 계열으로 + 지정한다. -{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} kubectl을 사용하여 셀렉터로 기존 헤드리스 서비스를 검사하여 이 동작의 유효성을 검사 할 수 있다. -```shell -kubectl get svc my-service -o yaml -``` + ```shell + kubectl get svc my-service -o yaml + ``` -```yaml -apiVersion: v1 -kind: Service -metadata: - labels: - app: MyApp - name: my-service -spec: - clusterIP: None - clusterIPs: - - None - ipFamilies: - - IPv4 - ipFamilyPolicy: SingleStack - ports: - - port: 80 - protocol: TCP - targetPort: 80 - selector: - app: MyApp -``` + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app: MyApp + name: my-service + spec: + clusterIP: None + clusterIPs: + - None + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app: MyApp + ``` #### 단일 스택과 이중 스택 간 서비스 전환 서비스는 단일 스택에서 이중 스택으로, 이중 스택에서 단일 스택으로 변경할 수 있다. -1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖게된다. +1. 서비스를 단일 스택에서 이중 스택으로 변경하려면 원하는 대로 `.spec.ipFamilyPolicy`를 + `SingleStack`에서 `PreferDualStack` 또는 `RequireDualStack`으로 변경한다. + 이 서비스를 단일 스택에서 이중 스택으로 변경하면 쿠버네티스는 누락된 주소 계열의 + 것을 배정하므로 해당 서비스는 이제 IPv4와 IPv6 주소를 갖는다. `.spec.ipFamilyPolicy`를 `SingleStack`에서 `PreferDualStack`으로 업데이트하는 서비스 사양을 편집한다. -이전: -```yaml -spec: - ipFamilyPolicy: SingleStack -``` -이후: -```yaml -spec: - ipFamilyPolicy: PreferDualStack -``` + 이전: -1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다. + ```yaml + spec: + ipFamilyPolicy: SingleStack + ``` + + 이후: + + ```yaml + spec: + ipFamilyPolicy: PreferDualStack + ``` + +1. 서비스를 이중 스택에서 단일 스택으로 변경하려면 `.spec.ipFamilyPolicy`를 + `PreferDualStack`에서 또는 `RequireDualStack`을 `SingleStack`으로 변경한다. + 이 서비스를 이중 스택에서 단일 스택으로 변경하면 쿠버네티스는 `.spec.ClusterIPs` + 배열의 첫 번째 요소 만 유지하고 `.spec.ClusterIP`를 해당 IP 주소로 설정하고 + `.spec.ipFamilies`를 `.spec.ClusterIPs`의 주소 계열로 설정한다. ### 셀렉터가 없는 헤드리스 서비스 -[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 `RequireDualStack` 이다. +[셀렉터가 없는 서비스](/ko/docs/concepts/services-networking/service/#셀렉터가-없는-서비스) 및 `.spec.ipFamilyPolicy`가 +명시적으로 설정되지 않은 경우 `.spec.ipFamilyPolicy` 필드의 기본값은 +`RequireDualStack` 이다. ### 로드밸런서 서비스 유형 서비스에 이중 스택 로드밸런서를 프로비저닝하려면 - * `.spec.type` 필드를 `LoadBalancer`로 설정 - * `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정 + +* `.spec.type` 필드를 `LoadBalancer`로 설정 +* `.spec.ipFamilyPolicy` 필드를 `PreferDualStack` 또는 `RequireDualStack`으로 설정 {{< note >}} -이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 IPv4 및 IPv6로드 밸런서를 지원해야 한다. +이중 스택 `LoadBalancer` 유형 서비스를 사용하려면 클라우드 공급자가 +IPv4 및 IPv6로드 밸런서를 지원해야 한다. {{< /note >}} ## 이그레스(Egress) 트래픽 -비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 (예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) 프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다. +비공개로 라우팅할 수 있는 IPv6 주소를 사용하는 파드에서 클러스터 외부 대상 +(예: 공용 인터넷)에 도달하기 위해 이그레스 트래픽을 활성화하려면 투명 프록시 또는 +IP 위장과 같은 메커니즘을 통해 공개적으로 라우팅한 IPv6 주소를 사용하도록 파드를 활성화해야 한다. +[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) +프로젝트는 이중 스택 클러스터에서 IP 위장을 지원한다. {{< note >}} {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 IPv6를 지원하는지 확인한다. {{< /note >}} +## 윈도우 지원 + +윈도우에 있는 쿠버네티스는 싱글 스택(single-stack) "IPv6-only" 네트워킹을 지원하지 않는다. 그러나, 싱글 패밀리(single-family) +서비스로 되어 있는 파드와 노드에 대해서는 듀얼 스택(dual-stack) IPv4/IPv6 네트워킹을 +지원한다. + +`l2bridge` 네트워크로 IPv4/IPv6 듀얼 스택 네트워킹을 사용할 수 있다. + +{{< note >}} +윈도우에서 오버레이 (VXLAN) 네트워크은 듀얼 스택 네트워킹을 **지원하지 않는다.** +{{< /note >}} + +윈도우의 다른 네트워크 모델에 대한 내용은 +[윈도우에서의 네트워킹](/docs/concepts/services-networking/windows-networking#network-modes)을 살펴본다. + ## {{% heading "whatsnext" %}} - * [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹 -* [kubeadm을 사용하여 이중 스택 네트워킹 활성화 -](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) +* [kubeadm을 사용하여 이중 스택 네트워킹 활성화](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) From 481177f8643842688bd352b2a9b6a9e76245f536 Mon Sep 17 00:00:00 2001 From: Nayeon Keum Date: Thu, 28 Jul 2022 21:38:10 +0900 Subject: [PATCH 062/202] Translate the glossary term Member into Korean Signed-off-by: Nayeon Keum --- content/ko/docs/reference/glossary/member.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 content/ko/docs/reference/glossary/member.md diff --git a/content/ko/docs/reference/glossary/member.md b/content/ko/docs/reference/glossary/member.md new file mode 100644 index 0000000000..c9a12ad7af --- /dev/null +++ b/content/ko/docs/reference/glossary/member.md @@ -0,0 +1,17 @@ +--- +title: 멤버(Member) +id: member +date: 2018-04-12 +full_link: +short_description: > + K8s 커뮤니티에서 지속적으로 활동하는 컨트리뷰터. + +aka: +tags: +- community +--- + K8s 커뮤니티에서 지속적으로 활동하는 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}. + + + +멤버는 이슈와 풀 리퀘스트를 할당받을 수 있으며 GitHub 팀을 통해 {{< glossary_tooltip text="SIG" term_id="sig" >}}에 참여할 수 있다. 멤버의 풀 리퀘스트에 대해 병합 전 테스트(pre-submit test)가 자동으로 실행된다. 멤버는 커뮤니티에 적극적으로 기여할 것으로 기대된다. From 9d30c45371875b37e939982630a727b82ffdc1c7 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Fri, 29 Jul 2022 12:46:19 +0900 Subject: [PATCH 063/202] [ko] Update outdated files in dev-1.24-ko.2 (M76-M79) --- .../tasks/administer-cluster/certificates.md | 398 ++++++++++-------- .../kubeadm/kubeadm-certs.md | 8 +- .../kubeadm/kubeadm-upgrade.md | 267 ++++++------ .../kubeadm/upgrading-windows-nodes.md | 31 +- 4 files changed, 387 insertions(+), 317 deletions(-) diff --git a/content/ko/docs/tasks/administer-cluster/certificates.md b/content/ko/docs/tasks/administer-cluster/certificates.md index 076f09faf4..3cbeae35fc 100644 --- a/content/ko/docs/tasks/administer-cluster/certificates.md +++ b/content/ko/docs/tasks/administer-cluster/certificates.md @@ -4,124 +4,156 @@ content_type: task weight: 20 --- - 클라이언트 인증서로 인증을 사용하는 경우 `easyrsa`, `openssl` 또는 `cfssl` 을 통해 인증서를 수동으로 생성할 수 있다. - - - ### easyrsa **easyrsa** 는 클러스터 인증서를 수동으로 생성할 수 있다. -1. easyrsa3의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다. +1. `easyrsa3`의 패치 버전을 다운로드하여 압축을 풀고, 초기화한다. - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki -1. 새로운 인증 기관(CA)을 생성한다. `--batch` 는 자동 모드를 설정한다. - `--req-cn` 는 CA의 새 루트 인증서에 대한 일반 이름(Common Name (CN))을 지정한다. + ```shell + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki + ``` +1. 새로운 인증 기관(CA)을 생성한다. `--batch` 는 자동 모드를 설정한다. + `--req-cn` 는 CA의 새 루트 인증서에 대한 일반 이름(Common Name (CN))을 지정한다. - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass -1. 서버 인증서와 키를 생성한다. - `--subject-alt-name` 인수는 API 서버에 접근이 가능한 IP와 DNS - 이름을 설정한다. `MASTER_CLUSTER_IP` 는 일반적으로 API 서버와 - 컨트롤러 관리자 컴포넌트에 대해 `--service-cluster-ip-range` 인수로 - 지정된 서비스 CIDR의 첫 번째 IP이다. `--days` 인수는 인증서가 만료되는 - 일 수를 설정하는데 사용된다. - 또한, 아래 샘플은 기본 DNS 이름으로 `cluster.local` 을 - 사용한다고 가정한다. + ```shell + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass + ``` - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ - "IP:${MASTER_CLUSTER_IP},"\ - "DNS:kubernetes,"\ - "DNS:kubernetes.default,"\ - "DNS:kubernetes.default.svc,"\ - "DNS:kubernetes.default.svc.cluster,"\ - "DNS:kubernetes.default.svc.cluster.local" \ - --days=10000 \ - build-server-full server nopass -1. `pki/ca.crt`, `pki/issued/server.crt` 그리고 `pki/private/server.key` 를 디렉터리에 복사한다. -1. API 서버 시작 파라미터에 다음 파라미터를 채우고 추가한다. +1. 서버 인증서와 키를 생성한다. - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key + `--subject-alt-name` 인자로 API 서버에 접근이 가능한 IP와 DNS + 이름을 설정한다. `MASTER_CLUSTER_IP` 는 일반적으로 API 서버와 + 컨트롤러 관리자 컴포넌트에 대해 `--service-cluster-ip-range` 인자로 + 지정된 서비스 CIDR의 첫 번째 IP이다. `--days` 인자는 인증서가 만료되는 + 일 수를 설정하는 데 사용된다. + 또한, 아래 샘플에서는 `cluster.local` 을 기본 DNS 도메인 + 이름으로 사용하고 있다고 가정한다. + + ```shell + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass + ``` + +1. `pki/ca.crt`, `pki/issued/server.crt` 그리고 `pki/private/server.key` 를 디렉터리에 복사한다. + +1. API 서버를 시작하는 파라미터에 다음과 같이 추가한다. + + ```shell + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + ``` ### openssl **openssl** 은 클러스터 인증서를 수동으로 생성할 수 있다. -1. ca.key를 2048bit로 생성한다. +1. ca.key를 2048bit로 생성한다. - openssl genrsa -out ca.key 2048 -1. ca.key에 따라 ca.crt를 생성한다(인증서 유효 기간을 사용하려면 -days를 사용한다). + ```shell + openssl genrsa -out ca.key 2048 + ``` - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt -1. server.key를 2048bit로 생성한다. +1. ca.key에 따라 ca.crt를 생성한다(인증서 유효 기간을 사용하려면 `-days`를 사용한다). - openssl genrsa -out server.key 2048 -1. 인증서 서명 요청(Certificate Signing Request (CSR))을 생성하기 위한 설정 파일을 생성한다. - 파일에 저장하기 전에 꺾쇠 괄호(예: ``)로 - 표시된 값을 실제 값으로 대체한다(예: `csr.conf`). - `MASTER_CLUSTER_IP` 의 값은 이전 하위 섹션에서 - 설명한 대로 API 서버의 서비스 클러스터 IP이다. - 또한, 아래 샘플에서는 `cluster.local` 을 기본 DNS 도메인 - 이름으로 사용하고 있다고 가정한다. + ```shell + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt + ``` - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn +1. server.key를 2048bit로 생성한다. - [ dn ] - C = <국가(country)> - ST = <도(state)> - L = <시(city)> - O = <조직(organization)> - OU = <조직 단위(organization unit)> - CN = + ```shell + openssl genrsa -out server.key 2048 + ``` - [ req_ext ] - subjectAltName = @alt_names +1. 인증서 서명 요청(Certificate Signing Request (CSR))을 생성하기 위한 설정 파일을 생성한다. - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = - IP.2 = + 파일에 저장하기 전에 꺾쇠 괄호(예: ``)로 + 표시된 값을 실제 값으로 대체한다(예: `csr.conf`). + `MASTER_CLUSTER_IP` 의 값은 이전 하위 섹션에서 + 설명한 대로 API 서버의 서비스 클러스터 IP이다. + 또한, 아래 샘플에서는 `cluster.local` 을 기본 DNS 도메인 + 이름으로 사용하고 있다고 가정한다. - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names -1. 설정 파일을 기반으로 인증서 서명 요청을 생성한다. + ```ini + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn - openssl req -new -key server.key -out server.csr -config csr.conf -1. ca.key, ca.crt 그리고 server.csr을 사용해서 서버 인증서를 생성한다. + [ dn ] + C = <국가(country)> + ST = <도(state)> + L = <시(city)> + O = <조직(organization)> + OU = <조직 단위(organization unit)> + CN = - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf -1. 인증서 서명 요청을 확인한다. + [ req_ext ] + subjectAltName = @alt_names - openssl req -noout -text -in ./server.csr -1. 인증서를 확인한다. + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = - openssl x509 -noout -text -in ./server.crt + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names + ``` + +1. 설정 파일을 기반으로 인증서 서명 요청을 생성한다. + + ```shell + openssl req -new -key server.key -out server.csr -config csr.conf + ``` + +1. ca.key, ca.crt 그리고 server.csr을 사용해서 서버 인증서를 생성한다. + + ```shell + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf + ``` + +1. 인증서 서명 요청을 확인한다. + + ```shell + openssl req -noout -text -in ./server.csr + ``` + +1. 인증서를 확인한다. + + ```shell + openssl x509 -noout -text -in ./server.crt + ``` 마지막으로, API 서버 시작 파라미터에 동일한 파라미터를 추가한다. @@ -129,101 +161,121 @@ weight: 20 **cfssl** 은 인증서 생성을 위한 또 다른 도구이다. -1. 아래에 표시된 대로 커맨드 라인 도구를 다운로드하여 압축을 풀고 준비한다. - 사용 중인 하드웨어 아키텍처 및 cfssl 버전에 따라 샘플 - 명령을 조정해야 할 수도 있다. +1. 아래에 표시된 대로 커맨드 라인 도구를 다운로드하여 압축을 풀고 준비한다. + + 사용 중인 하드웨어 아키텍처 및 cfssl 버전에 따라 샘플 + 명령을 조정해야 할 수도 있다. + + ```shell + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl + chmod +x cfssl + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson + chmod +x cfssljson + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo + ``` - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl - chmod +x cfssl - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson - chmod +x cfssljson - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo - chmod +x cfssl-certinfo 1. 아티팩트(artifact)를 보유할 디렉터리를 생성하고 cfssl을 초기화한다. - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json -1. CA 파일을 생성하기 위한 JSON 설정 파일을 `ca-config.json` 예시와 같이 생성한다. + ```shell + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json + ``` - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } -1. CA 인증서 서명 요청(CSR)을 위한 JSON 설정 파일을 +1. CA 파일을 생성하기 위한 JSON 설정 파일을 `ca-config.json` 예시와 같이 생성한다. + + ```json + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } + ``` + +1. CA 인증서 서명 요청(CSR)을 위한 JSON 설정 파일을 `ca-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호로 표시된 값을 사용하려는 실제 값으로 변경한다. - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "<국가(country)>", - "ST": "<도(state)>", - "L": "<시(city)>", - "O": "<조직(organization)>", - "OU": "<조직 단위(organization unit)>" - }] - } -1. CA 키(`ca-key.pem`)와 인증서(`ca.pem`)을 생성한다. + ```json + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "국가", + "ST": "도", + "L": "시", + "O": "조직", + "OU": "조직 단위" + }] + } + ``` - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca -1. API 서버의 키와 인증서를 생성하기 위한 JSON 구성파일을 - `server-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호 안의 값을 - 사용하려는 실제 값으로 변경한다. `MASTER_CLUSTER_IP` 는 - 이전 하위 섹션에서 설명한 API 서버의 클러스터 IP이다. - 아래 샘플은 기본 DNS 도메인 이름으로 `cluster.local` 을 - 사용한다고 가정한다. +1. CA 키(`ca-key.pem`)와 인증서(`ca.pem`)을 생성한다. - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "<국가(country)>", - "ST": "<도(state)>", - "L": "<시(city)>", - "O": "<조직(organization)>", - "OU": "<조직 단위(organization unit)>" - }] - } -1. API 서버 키와 인증서를 생성하면, 기본적으로 - `server-key.pem` 과 `server.pem` 파일에 각각 저장된다. + ```shell + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca + ``` - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ +1. API 서버의 키와 인증서를 생성하기 위한 JSON 구성파일을 + `server-csr.json` 예시와 같이 생성한다. 꺾쇠 괄호 안의 값을 + 사용하려는 실제 값으로 변경한다. `MASTER_CLUSTER_IP` 는 + 이전 하위 섹션에서 설명한 API 서버의 클러스터 IP이다. + 아래 샘플은 기본 DNS 도메인 이름으로 `cluster.local` 을 + 사용한다고 가정한다. + + ```json + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "<국가(country)>", + "ST": "<도(state)>", + "L": "<시(city)>", + "O": "<조직(organization)>", + "OU": "<조직 단위(organization unit)>" + }] + } + ``` + +1. API 서버 키와 인증서를 생성하면, 기본적으로 + `server-key.pem` 과 `server.pem` 파일에 각각 저장된다. + + ```shell + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ --config=ca-config.json -profile=kubernetes \ server-csr.json | ../cfssljson -bare server - + ``` ## 자체 서명된 CA 인증서의 배포 @@ -234,12 +286,12 @@ weight: 20 각 클라이언트에서, 다음 작업을 수행한다. -```bash +```shell sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt sudo update-ca-certificates ``` -``` +```none Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... @@ -248,6 +300,6 @@ done. ## 인증서 API -`certificates.k8s.io` API를 사용해서 -[여기](/ko/docs/tasks/tls/managing-tls-in-a-cluster/)에 +`certificates.k8s.io` API를 사용하여 +[클러스터에서 TLS 인증서 관리](/ko/docs/tasks/tls/managing-tls-in-a-cluster/)에 설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index c5fc28ba3f..784baf8d5d 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -1,6 +1,6 @@ --- - - +# reviewers: +# - sig-cluster-lifecycle title: kubeadm을 사용한 인증서 관리 content_type: task weight: 10 @@ -244,7 +244,7 @@ serverTLSBootstrap: true ``` 만약 이미 클러스터를 생성했다면 다음을 따라 이를 조정해야 한다. - - `kube-system` 네임스페이스에서 `kubelet-config-{{< skew latestVersion >}}` 컨피그맵을 찾아서 수정한다. + - `kube-system` 네임스페이스에서 `kubelet-config-{{< skew currentVersion >}}` 컨피그맵을 찾아서 수정한다. 해당 컨피그맵에는 `kubelet` 키가 [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 문서를 값으로 가진다. `serverTLSBootstrap: true` 가 되도록 KubeletConfiguration 문서를 수정한다. @@ -276,7 +276,7 @@ kubectl certificate approve `KubeletConfiguration` 필드의 `rotateCertificates` 를 `true` 로 설정한다. 이것은 만기가 다가오면 인증서를 위한 신규 CSR 세트가 생성되는 것을 의미하며, 해당 순환(rotation)을 완료하기 위해서는 승인이 되어야 한다는 것을 의미한다. 더 상세한 이해를 위해서는 -[인증서 순환](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)를 확인한다. +[인증서 순환](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#certificate-rotation)를 확인한다. 만약 이 CSR들의 자동 승인을 위한 솔루션을 찾고 있다면 클라우드 제공자와 연락하여 대역 외 메커니즘(out of band mechanism)을 통해 노드의 신분을 검증할 수 있는 diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index ad8e8d7529..0dfe0865d6 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -1,6 +1,6 @@ --- - - +# reviewers: +# - sig-cluster-lifecycle title: kubeadm 클러스터 업그레이드 content_type: task weight: 20 @@ -29,7 +29,7 @@ weight: 20 ## {{% heading "prerequisites" %}} -- [릴리스 노트]({{< latest-release-notes >}})를 주의 깊게 읽어야 한다. +- [릴리스 노트](https://git.k8s.io/kubernetes/CHANGELOG)를 주의 깊게 읽어야 한다. - 클러스터는 정적 컨트롤 플레인 및 etcd 파드 또는 외부 etcd를 사용해야 한다. - 데이터베이스에 저장된 앱-레벨 상태와 같은 중요한 컴포넌트를 반드시 백업한다. `kubeadm upgrade` 는 워크로드에 영향을 미치지 않고, 쿠버네티스 내부의 컴포넌트만 다루지만, 백업은 항상 모범 사례일 정도로 중요하다. @@ -79,83 +79,87 @@ OS 패키지 관리자를 사용하여 쿠버네티스의 최신 패치 릴리 **첫 번째 컨트롤 플레인 노드의 경우** -- kubeadm 업그레이드 +- kubeadm 업그레이드 -{{< tabs name="k8s_install_kubeadm_first_cp" >}} -{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # {{< skew currentVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다. - apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubeadm -{{% /tab %}} -{{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. - yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} + {{< tabs name="k8s_install_kubeadm_first_cp" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + ```shell + # {{< skew currentVersion >}}.x-00에서 x를 최신 패치 버전으로 바꾼다. + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubeadm + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + ```shell + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다. + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}}
-- 다운로드하려는 버전이 잘 받아졌는지 확인한다. +- 다운로드하려는 버전이 잘 받아졌는지 확인한다. - ```shell - kubeadm version - ``` + ```shell + kubeadm version + ``` -- 업그레이드 계획을 확인한다. +- 업그레이드 계획을 확인한다. - ```shell - kubeadm upgrade plan - ``` + ```shell + kubeadm upgrade plan + ``` - 이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. - 또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다. + 이 명령은 클러스터를 업그레이드할 수 있는지를 확인하고, 업그레이드할 수 있는 버전을 가져온다. + 또한 컴포넌트 구성 버전 상태가 있는 표를 보여준다. -{{< note >}} -또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. -인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다. -자세한 내용은 [인증서 관리 가이드](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. -{{}} + {{< note >}} + 또한 `kubeadm upgrade` 는 이 노드에서 관리하는 인증서를 자동으로 갱신한다. + 인증서 갱신을 하지 않으려면 `--certificate-renewal=false` 플래그를 사용할 수 있다. + 자세한 내용은 [인증서 관리 가이드](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs)를 참고한다. + {{}} -{{< note >}} -`kubeadm upgrade plan` 이 수동 업그레이드가 필요한 컴포넌트 구성을 표시하는 경우, 사용자는 -`--config` 커맨드 라인 플래그를 통해 대체 구성이 포함된 구성 파일을 `kubeadm upgrade apply` 에 제공해야 한다. -그렇게 하지 않으면 `kubeadm upgrade apply` 가 오류와 함께 종료되고 업그레이드를 수행하지 않는다. -{{}} + {{< note >}} + `kubeadm upgrade plan` 이 수동 업그레이드가 필요한 컴포넌트 구성을 표시하는 경우, 사용자는 + `--config` 커맨드 라인 플래그를 통해 대체 구성이 포함된 구성 파일을 `kubeadm upgrade apply` 에 제공해야 한다. + 그렇게 하지 않으면 `kubeadm upgrade apply` 가 오류와 함께 종료되고 업그레이드를 수행하지 않는다. + {{}} -- 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. +- 업그레이드할 버전을 선택하고, 적절한 명령을 실행한다. 예를 들면 다음과 같다. - ```shell - # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다. - sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x - ``` + ```shell + # 이 업그레이드를 위해 선택한 패치 버전으로 x를 바꾼다. + sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x + ``` - 명령이 완료되면 다음을 확인해야 한다. + 명령이 완료되면 다음을 확인해야 한다. - ``` - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! + ``` + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! - [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. - ``` + [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. + ``` -- CNI 제공자 플러그인을 수동으로 업그레이드한다. +- CNI 제공자 플러그인을 수동으로 업그레이드한다. - CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. - [애드온](/ko/docs/concepts/cluster-administration/addons/) 페이지에서 - 사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다. + CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다. + [애드온](/ko/docs/concepts/cluster-administration/addons/) 페이지에서 + 사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다. - CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다. + CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다. **다른 컨트롤 플레인 노드의 경우** 첫 번째 컨트롤 플레인 노드와 동일하지만 다음을 사용한다. -``` +```shell sudo kubeadm upgrade node ``` 아래 명령 대신 위의 명령을 사용한다. -``` +```shell sudo kubeadm upgrade apply ``` @@ -163,46 +167,50 @@ sudo kubeadm upgrade apply ### 노드 드레인 -- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: +- 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. - ```shell - # 을 드레인하는 노드의 이름으로 바꾼다. - kubectl drain --ignore-daemonsets - ``` + ```shell + # 을 드레인하는 노드의 이름으로 바꾼다. + kubectl drain --ignore-daemonsets + ``` ### kubelet과 kubectl 업그레이드 -- 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. +- 모든 컨트롤 플레인 노드에서 kubelet 및 kubectl을 업그레이드한다. -{{< tabs name="k8s_install_kubelet" >}} -{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # replace x in {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 - apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubelet kubectl -{{% /tab %}} -{{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} + {{< tabs name="k8s_install_kubelet" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubelet kubectl + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + ```shell + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}}
-- kubelet을 다시 시작한다. +- kubelet을 다시 시작한다. -```shell -sudo systemctl daemon-reload -sudo systemctl restart kubelet -``` + ```shell + sudo systemctl daemon-reload + sudo systemctl restart kubelet + ``` ### 노드 uncordon -- 노드를 스케줄 가능으로 표시하여 노드를 다시 온라인 상태로 전환한다. +- 노드를 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 전환한다. - ```shell - # 을 드레인하는 노드의 이름으로 바꾼다. - kubectl uncordon - ``` + ```shell + # 을 드레인하려는 노드의 이름으로 바꾼다. + kubectl uncordon + ``` ## 워커 노드 업그레이드 @@ -211,71 +219,79 @@ sudo systemctl restart kubelet ### kubeadm 업그레이드 -- 모든 워커 노드에서 kubeadm을 업그레이드한다. +- 모든 워커 노드에서 kubeadm을 업그레이드한다. -{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} -{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 - apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubeadm -{{% /tab %}} -{{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} + {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + ```shell + # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubeadm + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + ```shell + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} ### "kubeadm upgrade" 호출 -- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다. +- 워커 노드의 경우 로컬 kubelet 구성을 업그레이드한다. - ```shell - sudo kubeadm upgrade node - ``` + ```shell + sudo kubeadm upgrade node + ``` ### 노드 드레인 -- 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. +- 스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. - ```shell - # 을 드레이닝하려는 노드 이름으로 바꾼다. - kubectl drain --ignore-daemonsets - ``` + ```shell + # 을 드레인하려는 노드 이름으로 바꾼다. + kubectl drain --ignore-daemonsets + ``` ### kubelet과 kubectl 업그레이드 -- kubelet 및 kubectl을 업그레이드한다. +- kubelet 및 kubectl을 업그레이드한다. -{{< tabs name="k8s_kubelet_and_kubectl" >}} -{{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} - # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 - apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubelet kubectl -{{% /tab %}} -{{% tab name="CentOS, RHEL 또는 Fedora" %}} - # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 - yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} + {{< tabs name="k8s_kubelet_and_kubectl" >}} + {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} + ```shell + # {{< skew currentVersion >}}.x-00의 x를 최신 패치 버전으로 바꾼다 + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubelet kubectl + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL 또는 Fedora" %}} + ```shell + # {{< skew currentVersion >}}.x-0에서 x를 최신 패치 버전으로 바꾼다 + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}}
-- kubelet을 다시 시작한다. +- kubelet을 다시 시작한다. - ```shell - sudo systemctl daemon-reload - sudo systemctl restart kubelet - ``` + ```shell + sudo systemctl daemon-reload + sudo systemctl restart kubelet + ``` ### 노드에 적용된 cordon 해제 - 스케줄 가능(schedulable)으로 표시하여 노드를 다시 온라인 상태로 만든다. - ```shell - # 을 노드의 이름으로 바꾼다. - kubectl uncordon - ``` + ```shell + # 을 노드의 이름으로 바꾼다. + kubectl uncordon + ``` ## 클러스터 상태 확인 @@ -296,6 +312,7 @@ kubectl get nodes 잘못된 상태에서 복구하기 위해, 클러스터가 실행 중인 버전을 변경하지 않고 `kubeadm upgrade apply --force` 를 실행할 수도 있다. 업그레이드하는 동안 kubeadm은 `/etc/kubernetes/tmp` 아래에 다음과 같은 백업 폴더를 작성한다. + - `kubeadm-backup-etcd--