From f57fe73c5ee9e36f418ec4ac6228047a3e6e14e9 Mon Sep 17 00:00:00 2001 From: zhanwang Date: Sun, 1 Nov 2020 17:10:55 +0000 Subject: [PATCH 01/46] Update uk translation in README-uk.md --- README-uk.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README-uk.md b/README-uk.md index f437535353..2872b406d1 100644 --- a/README-uk.md +++ b/README-uk.md @@ -18,7 +18,8 @@ ```bash git clone https://github.com/kubernetes/website.git cd website -hugo server --buildFuture +git submodule update --init --recursive --depth 1 +make serve ``` @@ -82,4 +83,4 @@ hugo server --buildFuture ## Дякуємо! -Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! \ No newline at end of file +Долучення до спільноти - запорука успішного розвитку Kubernetes. Ми цінуємо ваш внесок у наш сайт і документацію! From 4d44cd3ae183a5bfeb22c5fcd205c0c95385e6b6 Mon Sep 17 00:00:00 2001 From: TAKAHASHI Shuuji Date: Thu, 5 Nov 2020 21:02:21 +0900 Subject: [PATCH 02/46] Add comments for the commands in Makefile. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 58babc3627..ea1c4797af 100644 --- a/Makefile +++ b/Makefile @@ -58,7 +58,7 @@ docker-serve: @echo -e "$(CCRED)**** The use of docker-serve is deprecated. Use container-serve instead. ****$(CCEND)" $(MAKE) container-serve -container-image: +container-image: ## Build a container image for the preview of the website $(CONTAINER_ENGINE) build . \ --network=host \ --tag $(CONTAINER_IMAGE) \ @@ -67,7 +67,7 @@ container-image: container-build: module-check $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" -container-serve: module-check +container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir test-examples: From 02d715ee133cd05deb3732435cf5858361984d17 Mon Sep 17 00:00:00 2001 From: Ray Wang Date: Tue, 1 Dec 2020 14:51:49 +0800 Subject: [PATCH 03/46] Add [version-menu] section into /i18n/zh.toml --- i18n/zh.toml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/i18n/zh.toml b/i18n/zh.toml index 4980f8d7fa..37387efa2a 100644 --- a/i18n/zh.toml +++ b/i18n/zh.toml @@ -211,6 +211,9 @@ other = "您的 Kubernetes 服务器版本必须不低于版本 " [version_check_tocheck] other = "要获知版本信息，请输入 " +[version_menu] +other = "版本列表" + [warning] other = "警告：" From f2a9a3ef81d3b2194a971e1281843adc95d28a25 Mon Sep 17 00:00:00 2001 From: Adam Jacob Date: Fri, 6 Nov 2020 09:03:46 -0800 Subject: [PATCH 04/46] Explain the insecure by default nature of secrets This PR adds a paragraph explaining the insecure by default nature of k8s secrets, and points users at the documentation to turn on encryption at rest and RBAC. I think a second page needs to be created showing the correct combination of RBAC rules for various cases, which should eventually replace the link to the RBAC documentation. --- content/en/docs/concepts/configuration/secret.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index 572072dd3e..1cd031fd51 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -24,6 +24,16 @@ a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates some Secrets. +{{< caution >}} +Kubernetes Secrets are, by default, stored as unencrypted base64-encoded +strings. By default they can be retrieved - as plain text - by anyone with API +access, or anyone with access to Kubernetes' underlying data store, etcd. In +order to safely use Secrets, we recommend you (at a minimum): + +1. [Enable Encryption at Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for Secrets. +2. [Enable RBAC rules that restrict reading and writing the Secret](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod. +{{< /caution >}} + ## Overview of Secrets From a51a653764939d25c02d4efff7754436b7ccaeb9 Mon Sep 17 00:00:00 2001 From: Antoine Pelisse Date: Sun, 13 Dec 2020 20:43:29 -0800 Subject: [PATCH 05/46] Clarify compatibility guarantees around spec.preserveUnknownFields --- .../custom-resources/custom-resource-definitions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index f69859eb2d..c24c1a18a8 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -314,7 +314,7 @@ CustomResourceDefinitions store validated resource data in the cluster's persist {{< note >}} CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`. -For migrated CustomResourceDefinitions where `spec.preserveUnknownFields` is set, pruning is _not_ enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set `spec.preserveUnknownFields` to true for the CustomResourceDefinition itself. +For legacy CustomResourceDefinitions created as `apiextensions.k8s.io/v1beta1` where spec.preserveUnknownFields is set to true, pruning is not enabled and you can store arbitrary data. For compatibility with `apiextensions.k8s.io/v1`, you should update your custom resources definition to (1) have a structural OpenAPI schema, and (2) you should set spec.preserveUnknownFields to false. In Kubernetes 1.22 the `apiextensions.k8s.io/v1beta1` API will be removed, and every CustomResourceDefinition must be created via `apiextensions/v1`, and this enforces both (1) and (2). {{< /note >}} If you save the following YAML to `my-crontab.yaml`: From 817cfb9f418022541df401f282d5e686ef564d8d Mon Sep 17 00:00:00 2001 From: Shu Muto Date: Thu, 17 Dec 2020 17:49:49 +0900 Subject: [PATCH 06/46] Remove Static Password File section Due to removed on v1.19, remove Static Password File section from docs/reference/access-authn-authz/authentication.md --- .../reference/access-authn-authz/authentication.md | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md index 3f713636f3..14875c8229 100644 --- a/content/ja/docs/reference/access-authn-authz/authentication.md +++ b/content/ja/docs/reference/access-authn-authz/authentication.md @@ -105,19 +105,6 @@ APIサーバーの`--enable-bootstrap-token-auth`フラグで、Bootstrap Token ブートストラップトークンの認証機能やコントローラーについての詳細な説明、`kubeadm`でこれらのトークンを管理する方法については、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)を参照してください。 -### 静的なパスワードファイル - -APIサーバーに`--basic-auth-file=SOMEFILE`オプションを渡すことで、Basic認証を有効にすることができます。現在のところ、Basic認証の認証情報は有効期限が無く、APIサーバーを再起動しない限りパスワードを変更することはできません。よりセキュアなモードをさらに使いやすくするための改良が完了するまでの間、現時点では利便性のためにBasic認証がサポートされていることに注意してください。 - -Basic認証ファイルは、トークン、ユーザー名、ユーザーIDの少なくとも3つの列を持つcsvファイルです。 -Kubernetesのバージョン1.6以降では、オプションとしてカンマ区切りのグループ名を含む4列目を指定することができます。複数のグループがある場合は、4列目の値をダブルクォート(")で囲む必要があります。以下の例を参照してください。 - -```conf -password,user,uid,"group1,group2,group3" -``` - -HTTPクライアントからBasic認証を利用する場合、APIサーバーは`Basic BASE64ENCODED(USER:PASSWORD)`の値を持つ`Authorization`ヘッダーを待ち受けます。 - ### サービスアカウントトークン サービスアカウントは、自動的に有効化される認証機能で、署名されたBearerトークンを使ってリクエストを検証します。このプラグインは、オプションとして2つのフラグを取ります。 From ac8b4c5399d9203262376a435df41dbc2f30d324 Mon Sep 17 00:00:00 2001 From: Nate W <4453979+nate-double-u@users.noreply.github.com> Date: Fri, 27 Nov 2020 16:37:27 -0800 Subject: [PATCH 07/46] Updating /docs/tasks/tools/install-kubectl Adding instructions for how to validate kubectl binaries against checksum files (Linux, MacOS, Windows) Updating links to download from https://dl.k8s.io/ Updating Linux-specific install instructions to use install command, and macOS-specific instructions to chown root the install to provide a trusted kubectl. Adding note annotation around optional download instructions Markdown updates * Updating numbered lists to use markdown syntax ("1." for each entry), should make it easier to add and remove list items in future * Adding some syntax highlighting to the command snippets Correcting "PowerShell" spelling fixes: https://github.com/kubernetes/website/issues/25040 Signed-off-by: Nate W <4453979+nate-double-u@users.noreply.github.com> --- .../en/docs/tasks/tools/install-kubectl.md | 204 +++++++++++++----- 1 file changed, 152 insertions(+), 52 deletions(-) diff --git a/content/en/docs/tasks/tools/install-kubectl.md b/content/en/docs/tasks/tools/install-kubectl.md index 5bfebd226b..54f1e7e123 100644 --- a/content/en/docs/tasks/tools/install-kubectl.md +++ b/content/en/docs/tasks/tools/install-kubectl.md @@ -32,34 +32,73 @@ Using the latest version of kubectl helps avoid unforeseen issues. 1. Download the latest release with the command: - ``` - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl" - ``` + ```bash + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" + ``` - To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. + {{< note >}} +To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. - For example, to download version {{< param "fullversion" >}} on Linux, type: - - ``` - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl - ``` +For example, to download version {{< param "fullversion" >}} on Linux, type: -2. Make the kubectl binary executable. + ```bash + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl + ``` + {{< /note >}} - ``` - chmod +x ./kubectl - ``` +1. Validate the binary (optional) -3. Move the binary in to your PATH. + Download the kubectl checksum file: - ``` - sudo mv ./kubectl /usr/local/bin/kubectl - ``` -4. Test to ensure the version you installed is up-to-date: + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" + ``` - ``` - kubectl version --client - ``` + Validate the kubectl binary against the checksum file: + + ```bash + echo "$(}} + Download the same version of the binary and checksum. + {{< /note >}} + +1. Install kubectl + + ```bash + sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl + ``` + + {{< note >}} + If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory: + + ```bash + mkdir -p ~/.local/bin/kubectl + mv ./kubectl ~/.local/bin/kubectl + # and then add ~/.local/bin/kubectl to $PATH + ``` + + {{< /note >}} + +1. Test to ensure the version you installed is up-to-date: + + ```bash + kubectl version --client + ``` ### Install using native package management @@ -120,30 +159,65 @@ kubectl version --client 1. Download the latest release: ```bash - curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl" + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" ``` - To download a specific version, replace the `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` portion of the command with the specific version. + {{< note >}} + To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. For example, to download version {{< param "fullversion" >}} on macOS, type: ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` - Make the kubectl binary executable. + {{< /note >}} + +1. Validate the binary (optional) + + Download the kubectl checksum file: + + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" + ``` + + Validate the kubectl binary against the checksum file: + + ```bash + echo "$(}} + Download the same version of the binary and checksum. + {{< /note >}} + +1. Make the kubectl binary executable. ```bash chmod +x ./kubectl ``` -3. Move the binary in to your PATH. +1. Move the kubectl binary to a file location on your system `PATH`. ```bash - sudo mv ./kubectl /usr/local/bin/kubectl + sudo mv ./kubectl /usr/local/bin/kubectl && \ + sudo chown root: /usr/local/bin/kubectl ``` -4. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```bash kubectl version --client @@ -165,7 +239,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you brew install kubernetes-cli ``` -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```bash kubectl version --client @@ -182,7 +256,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, sudo port install kubectl ``` -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```bash kubectl version --client @@ -192,47 +266,72 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, ### Install kubectl binary with curl on Windows -1. Download the latest release {{< param "fullversion" >}} from [this link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). +1. Download the [latest release {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). Or if you have `curl` installed, use this command: - ```bash - curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + ```powershell + curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe ``` - To find out the latest stable version (for example, for scripting), take a look at [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt). + {{< note >}} + To find out the latest stable version (for example, for scripting), take a look at [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt). + {{< /note >}} -2. Add the binary in to your PATH. +1. Validate the binary (optional) -3. Test to ensure the version of `kubectl` is the same as downloaded: + Download the kubectl checksum file: - ```bash + ```powershell + curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256 + ``` + + Validate the kubectl binary against the checksum file: + + - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded: + + ```cmd + CertUtil -hashfile kubectl.exe SHA256 + type kubectl.exe.sha256 + ``` + + - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: + + ```powershell + $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) + ``` + +1. Add the binary in to your `PATH`. + +1. Test to ensure the version of `kubectl` is the same as downloaded: + + ```cmd kubectl version --client ``` {{< note >}} -[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to PATH. -If you have installed Docker Desktop before, you may need to place your PATH entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`. +[Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/#kubernetes) adds its own version of `kubectl` to `PATH`. +If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`. {{< /note >}} -### Install with Powershell from PSGallery +### Install with PowerShell from PSGallery -If you are on Windows and using [Powershell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with Powershell. +If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell. 1. Run the installation commands (making sure to specify a `DownloadLocation`): ```powershell Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force install-kubectl.ps1 [-DownloadLocation ] - ``` + ``` {{< note >}} - If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's temp Directory. + If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory. {{< /note >}} The installer creates `$HOME/.kube` and instructs it to create a config file. -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```powershell kubectl version --client @@ -260,32 +359,32 @@ Updating the installation is performed by rerunning the two commands listed in s {{< /tabs >}} -2. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```powershell kubectl version --client ``` -3. Navigate to your home directory: +1. Navigate to your home directory: ```powershell # If you're using cmd.exe, run: cd %USERPROFILE% cd ~ ``` -4. Create the `.kube` directory: +1. Create the `.kube` directory: ```powershell mkdir .kube ``` -5. Change to the `.kube` directory you just created: +1. Change to the `.kube` directory you just created: ```powershell cd .kube ``` -6. Configure kubectl to use a remote Kubernetes cluster: +1. Configure kubectl to use a remote Kubernetes cluster: ```powershell New-Item config -type file @@ -301,13 +400,13 @@ You can install kubectl as part of the Google Cloud SDK. 1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/). -2. Run the `kubectl` installation command: +1. Run the `kubectl` installation command: ```shell gcloud components install kubectl ``` -3. Test to ensure the version you installed is up-to-date: +1. Test to ensure the version you installed is up-to-date: ```shell kubectl version --client @@ -385,11 +484,13 @@ You now need to ensure that the kubectl completion script gets sourced in all yo ```bash echo 'source <(kubectl completion bash)' >>~/.bashrc ``` + - Add the completion script to the `/etc/bash_completion.d` directory: ```bash kubectl completion bash >/etc/bash_completion.d/kubectl ``` + If you have an alias for kubectl, you can extend shell completion to work with that alias: ```bash @@ -470,7 +571,6 @@ You now have to ensure that the kubectl completion script gets sourced in all yo ```bash echo 'source <(kubectl completion bash)' >>~/.bash_profile - ``` - Add the completion script to the `/usr/local/etc/bash_completion.d` directory: From 03a336a9468e0ba90bcc52a8b2092d9e4577f543 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Wed, 23 Dec 2020 13:58:54 +0800 Subject: [PATCH 08/46] Remove link to empty list for k8s metrics --- .../en/docs/concepts/cluster-administration/system-metrics.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/system-metrics.md b/content/en/docs/concepts/cluster-administration/system-metrics.md index bbfdf0cc0c..3c7e137ded 100644 --- a/content/en/docs/concepts/cluster-administration/system-metrics.md +++ b/content/en/docs/concepts/cluster-administration/system-metrics.md @@ -156,5 +156,4 @@ endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1 ## {{% heading "whatsnext" %}} * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics -* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) From 37b5cb9e2a45796f50d668e267ceb5fe07d58fef Mon Sep 17 00:00:00 2001 From: Roman Marusyk Date: Mon, 28 Dec 2020 23:56:44 +0200 Subject: [PATCH 09/46] Add tooltip for CSI --- content/en/docs/concepts/storage/persistent-volumes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 2d1064ed7c..848312b5b8 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -231,7 +231,7 @@ the following types of volumes: * Azure Disk * Portworx * FlexVolumes -* CSI +* {{< glossary_tooltip text="CSI" term_id="csi" >}} You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true. From 04f75e4891328fcca42ef2294ec54e798c59859d Mon Sep 17 00:00:00 2001 From: PyungHo Yoon Date: Tue, 29 Dec 2020 18:56:45 +0900 Subject: [PATCH 10/46] Add a Korean l10n reviewer to OWNERS_ALIASES --- OWNERS_ALIASES | 1 + 1 file changed, 1 insertion(+) diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 3d1ae50afa..5914f636e2 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -139,6 +139,7 @@ aliases: - seokho-son - ysyukr - pjhwa + - yoonian sig-docs-leads: # Website chairs and tech leads - irvifa - jimangel From 8f776e275d3d6487e87cb28fda14cb855b9f16fb Mon Sep 17 00:00:00 2001 From: seokho-son Date: Mon, 14 Dec 2020 15:16:51 +0900 Subject: [PATCH 11/46] Enhance diff_l10n_branches script output --- scripts/diff_l10n_branches.py | 79 ++++++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 11 deletions(-) diff --git a/scripts/diff_l10n_branches.py b/scripts/diff_l10n_branches.py index 5da4cabcc5..e4bbf46593 100755 --- a/scripts/diff_l10n_branches.py +++ b/scripts/diff_l10n_branches.py @@ -13,17 +13,17 @@ Outdated files in the {{ r_commit }} branch. ### {{ files_to_be_modified | count }} files to be modified {% for m_file in files_to_be_modified -%} - 1. [ ] {{ m_file.filepath }} {{ m_file.shortstat }} + 1. [ ] {{ m_file.fileindex }} `{{ m_file.filepath }}` {{ m_file.stat }} {% endfor %} ### {{ files_to_be_renamed | count }} files to be renamed {% for r_file in files_to_be_renamed -%} - 1. [ ] {{ r_file.diff_status_letter }} {{ r_file.src_filepath }} -> {{ r_file.dest_filepath }} + 1. [ ] {{ r_file.fileindex }} {{ r_file.diff_status_letter }} `{{ r_file.src_filepath }}` -> `{{ r_file.dest_filepath }}` {% endfor %} ### {{ files_to_be_deleted | count }} files to be deleted {% for d_file in files_to_be_deleted -%} - 1. [ ] {{ d_file }} + 1. [ ] {{ d_file.fileindex }} `{{ d_file.filepath }}` {% endfor %} ## Proposed Solution @@ -51,18 +51,23 @@ vi {{ files_to_be_modified.0.filepath | replace(src_lang_path, l10n_lang_path) } ## Pages to Update +Pages in {{ l10n_lang_path }} + """ files_to_be_deleted = [] files_to_be_renamed = [] files_to_be_modified = [] +index_to_be_deleted = 0 +index_to_be_renamed = 0 +index_to_be_modified = 0 -def git_diff(filepath, l_commit, r_commit, shortstat=False): +def git_diff(filepath, l_commit, r_commit, stat=False): cmd = ["git", "diff", l_commit, r_commit, "--", filepath] - if shortstat: - cmd = ["git", "diff", l_commit, r_commit, "--shortstat", "--", filepath] + if stat: + cmd = ["git", "diff", l_commit, r_commit, "--stat", "--", filepath] return subprocess.check_output(cmd).decode("UTF-8").strip() @@ -78,18 +83,70 @@ def process_diff_status(diff_status, l_commit, r_commit, src_lang_path, status_letter = diff_status[0] filepath = diff_status[1] + size_xs = 10 + size_s = 30 + size_m = 100 + size_l = 500 + size_xl = 1000 + if git_exists(r_commit, filepath.replace(src_lang_path, l10n_lang_path)): if status_letter == 'D': - files_to_be_deleted.append(filepath) + global index_to_be_deleted + index_to_be_deleted += 1 + fileindex = "D" + str(index_to_be_deleted) + '. ' + deleted = {"fileindex": fileindex, + "filepath": filepath } + files_to_be_deleted.append(deleted) elif status_letter.startswith('R'): - replaced = {"diff_status_letter": diff_status[0], + global index_to_be_renamed + index_to_be_renamed += 1 + fileindex = "R" + str(index_to_be_renamed) + '. ' + replaced = {"fileindex": fileindex, + "diff_status_letter": diff_status[0], "src_filepath": diff_status[1], "dest_filepath": diff_status[2]} files_to_be_renamed.append(replaced) elif status_letter == 'M': - modified = {"filepath": filepath, - "shortstat": git_diff(filepath, l_commit, r_commit, - shortstat=True), + global index_to_be_modified + index_to_be_modified += 1 + diff_string = git_diff(filepath, l_commit, r_commit, stat=True) + diff_string_tmp= diff_string.split("|") + diff_string_r = diff_string_tmp[1] + + res = [int(i) for i in diff_string_r.split() if i.isdigit()] + if len(res) < 4 : + res.append(0) + + insertions = res[2] + deletions = res[3] + + bold_condition = size_m + if insertions < size_xs : + insertion_size = "XS" + elif insertions < size_s : + insertion_size = "S" + elif insertions < size_m : + insertion_size = "M" + elif insertions < size_l : + insertion_size = "L" + elif insertions < size_xl : + insertion_size = "XL" + else : + insertion_size = "XXL" + + stat_output = str(insertions) + "(+" + insertion_size + ") " + str(deletions) + "(-)" + + if insertions >= bold_condition : + fileindex = "**M" + str(index_to_be_modified) + ".** " + stat_output = "**" + stat_output + "**" + else : + fileindex = "M" + str(index_to_be_modified) + ". " + + stat_output = " | " + stat_output + + modified = {"fileindex": fileindex, + "filepath": filepath, + "stat": stat_output, "diff": git_diff(filepath, l_commit, r_commit)} files_to_be_modified.append(modified) From bf4c9676ea99ab27a1842c676259494642d752de Mon Sep 17 00:00:00 2001 From: Shinjiro Sugita <32549076+jiroshin@users.noreply.github.com> Date: Wed, 6 Jan 2021 12:25:02 +0900 Subject: [PATCH 12/46] fix typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit L460: fix「ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下をを書き換えます」→ 「ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下を書き換えます」 --- content/ja/docs/concepts/configuration/secret.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index 26ce98ab50..9ae7c55067 100644 --- a/content/ja/docs/concepts/configuration/secret.md +++ b/content/ja/docs/concepts/configuration/secret.md @@ -457,7 +457,7 @@ Secretは直接Podが参照できるようにはされず、システムの別 PodのボリュームとしてSecretを使うには、 1. Secretを作成するか既存のものを使用します。複数のPodが同一のSecretを参照することができます。 -1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下をを書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。 +1. ボリュームを追加するため、Podの定義の`.spec.volumes[]`以下を書き換えます。ボリュームに命名し、`.spec.volumes[].secret.secretName`フィールドはSecretオブジェクトの名称と同一にします。 1. Secretを必要とするそれぞれのコンテナに`.spec.containers[].volumeMounts[]`を追加します。`.spec.containers[].volumeMounts[].readOnly = true`を指定して`.spec.containers[].volumeMounts[].mountPath`をSecretをマウントする未使用のディレクトリ名にします。 1. イメージやコマンドラインを変更し、プログラムがそのディレクトリを参照するようにします。連想配列`data`のキーは`mountPath`以下のファイル名になります。 From 7eb46bb8c6e1756f9fedc60a80512bdda5de24e7 Mon Sep 17 00:00:00 2001 From: ydFu Date: Sat, 9 Jan 2021 12:17:25 +0800 Subject: [PATCH 13/46] Document kubeadm for RHEL 8 * Add forward compatibility RHEL / CentOS to the list of supported platforms. --- .../production-environment/tools/kubeadm/install-kubeadm.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 9d0853b824..7c44f6e689 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 @@ -21,8 +21,8 @@ For information how to create a cluster with kubeadm once you have performed thi * One or more machines running one of: - Ubuntu 16.04+ - Debian 9+ - - CentOS 7 - - Red Hat Enterprise Linux (RHEL) 7 + - CentOS 7+ + - Red Hat Enterprise Linux (RHEL) 7+ - Fedora 25+ - HypriotOS v1.0.1+ - Flatcar Container Linux (tested with 2512.3.0) From ad119319ccb9cbd2d232475cd53820e614ca81d1 Mon Sep 17 00:00:00 2001 From: Wen Ming Date: Sat, 9 Jan 2021 14:39:47 +0800 Subject: [PATCH 14/46] Update ingress-controllers.md add Apache APISIX ingress controller --- .../en/docs/concepts/services-networking/ingress-controllers.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index df0e3ffd22..0209ce1a13 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -26,6 +26,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet * [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress controller. +* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller. * The [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) works with Citrix Application Delivery Controller. * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller. From a88a70492f0847fa641030aedfe09dad5aeac188 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 10 Jan 2021 15:45:50 +0800 Subject: [PATCH 15/46] [zh] Resync concepts/services-networking/ingress-controllers.md --- .../ingress-controllers.md | 148 +++++++++--------- 1 file changed, 72 insertions(+), 76 deletions(-) diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index 6b31e610d6..fac1adf2f7 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -19,16 +19,18 @@ Unlike other types of controllers which run as part of the `kube-controller-mana are not started automatically with a cluster. Use this page to choose the ingress controller implementation that best fits your cluster. -Kubernetes as a project currently supports and maintains [GCE](https://git.k8s.io/ingress-gce/README.md) and - [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers. +Kubernetes as a project supports and maintains [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme), and + [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) ingress controllers. --> 为了让 Ingress 资源工作，集群必须有一个正在运行的 Ingress 控制器。 与作为 `kube-controller-manager` 可执行文件的一部分运行的其他类型的控制器不同，Ingress 控制器不是随集群自动启动的。 基于此页面，你可选择最适合你的集群的 ingress 控制器实现。 -Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/ingress-gce/README.md) -和 [nginx](https://git.k8s.io/ingress-nginx/README.md) 控制器。 +Kubernetes 作为一个项目，目前支持和维护 +[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)， +[GCE](https://git.k8s.io/ingress-gce/README.md) +和 [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) Ingress 控制器。 @@ -37,80 +39,74 @@ Kubernetes 作为一个项目，目前支持和维护 [GCE](https://git.k8s.io/i --> ## 其他控制器 - -* [AKS 应用程序网关 Ingress 控制器]使用 - [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview)启用 - [AKS 集群](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) ingress。 -* [Ambassador](https://www.getambassador.io/) API 网关，一个基于 [Envoy](https://www.envoyproxy.io) 的 Ingress - 控制器，有着来自[社区](https://www.getambassador.io/docs) 的支持和来自 - [Datawire](https://www.datawire.io/) 的[商业](https://www.getambassador.io/pro/) 支持。 -* [AppsCode Inc.](https://appscode.com) 为最广泛使用的基于 - [HAProxy](https://www.haproxy.org/) 的 Ingress 控制器 - [Voyager](https://appscode.com/products/voyager) 提供支持和维护。 -* [AWS ALB Ingress 控制器](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) - 通过 [AWS 应用 Load Balancer](https://aws.amazon.com/elasticloadbalancing/) 启用 Ingress。 -* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) - 的 Ingress 控制器，它由 VMware 提供和支持。 - -* Citrix 为其硬件（MPX），虚拟化（VPX）和 - [免费容器化 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) - 提供了一个 [Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller)， - 用于[裸金属](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)和 - [云](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)部署。 -* F5 Networks 为 - [用于 Kubernetes 的 F5 BIG-IP 控制器](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)提供 - [支持和维护](https://support.f5.com/csp/article/K86859508)。 -* [Gloo](https://gloo.solo.io) 是一个开源的基于 - [Envoy](https://www.envoyproxy.io) 的 Ingress 控制器，它提供了 API 网关功能， - 有着来自 [solo.io](https://www.solo.io) 的企业级支持。 -* [HAProxy Ingress](https://haproxy-ingress.github.io) 是 HAProxy 高度可定制的、 - 由社区驱动的 Ingress 控制器。 -* [HAProxy Technologies](https://www.haproxy.com/) 为 - [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress) - 提供支持和维护。具体信息请参考[官方文档](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)。 -* 基于 [Istio](https://istio.io/) 的 ingress 控制器 - [控制 Ingress 流量](https://istio.io/docs/tasks/traffic-management/ingress/)。 - -* [Kong](https://konghq.com/) 为 - [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller) - 提供[社区](https://discuss.konghq.com/c/kubernetes)或 - [商业](https://konghq.com/kong-enterprise/)支持和维护。 -* [NGINX, Inc.](https://www.nginx.com/) 为 - [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) - 提供支持和维护。 -* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 路由器和反向代理，用于服务组合，包括诸如 Kubernetes Ingress 之类的用例，被设计为用于构建自定义代理的库。 -* [Traefik](https://github.com/traefik/traefik) 是一个全功能的 Ingress 控制器。 - （[Let's Encrypt](https://letsencrypt.org)，secrets，http2，websocket）， - 并且它也有来自 [Traefik Labs](https://traefik.io) 的商业支持。 +* [AKS 应用程序网关 Ingress 控制器](https://azure.github.io/application-gateway-kubernetes-ingress/) + 是一个配置 [Azure 应用程序网关](https://docs.microsoft.com/azure/application-gateway/overview) + 的 Ingress 控制器。 +* [Ambassador](https://www.getambassador.io/) API 网关是一个基于 [Envoy](https://www.envoyproxy.io) 的 Ingress + 控制器。 +* [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) + 使用 [VMware NSX Advanced Load Balancer](https://avinetworks.com/) + 提供第 4 到第 7 层的负载均衡。 +* [Citrix Ingress 控制器](https://github.com/citrix/citrix-k8s-ingress-controller#readme) + 可以用来与 Citrix Application Delivery Controller 一起使用。 +* [Contour](https://projectcontour.io/) 是一个基于 [Envoy](https://www.envoyproxy.io/) 的 Ingress 控制器。 + +* F5 BIG-IP 的 + [用于 Kubernetes 的容器 Ingress 服务](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest) + 让你能够使用 Ingress 来配置 F5 BIG-IP 虚拟服务器。 +* [Gloo](https://gloo.solo.io) 是一个开源的、基于 [Envoy](https://www.envoyproxy.io) 的 + Ingress 控制器，能够提供 API 网关功能， +* [HAProxy Ingress](https://haproxy-ingress.github.io/) 针对 [HAProxy](http://www.haproxy.org/#desc) + 的 Ingress 控制器。 +* [用于 Kubernetes 的 HAProxy Ingress 控制器](https://github.com/haproxytech/kubernetes-ingress#readme) + 也是一个针对 [HAProxy](http://www.haproxy.org/#desc) 的 Ingress 控制器。 +* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/) + 是一个基于 [Istio](https://istio.io/) 的 Ingress 控制器。 + +* [用于 Kubernetes 的 Kong Ingress 控制器](https://github.com/Kong/kubernetes-ingress-controller#readme) + 是一个用来驱动 [Kong Gateway](https://konghq.com/kong/) 的 Ingress 控制器。 +* [用于 Kubernetes 的 NGINX Ingress 控制器](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) + 能够与 [NGINX](https://www.nginx.com/resources/glossary/nginx/) Web 服务器（作为代理） + 一起使用。 +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP + 路由器和反向代理可用于服务组装，支持包括 Kubernetes Ingress 这类使用场景， + 设计用来作为构造你自己的定制代理的库。 +* [Traefik Kubernetes Ingress 提供程序](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) + 是一个用于 [Traefik](https://traefik.io/traefik/) 代理的 Ingress 控制器。 +* [Voyager](https://appscode.com/products/voyager) 是一个针对 [HAProxy](http://www.haproxy.org/#desc) + 的 Ingress 控制器。 +Kubernetes Pods 有[确定的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。 +例如，一旦某 Pod 在你的集群中运行，Pod 运行所在的 {{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时， 所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态： -即使节点后来恢复正常运行，你也需要创建新的 Pod。 +即使该节点后来恢复正常运行，你也需要创建新的 Pod 来恢复应用。 不过，为了让用户的日子略微好过一些，你并不需要直接管理每个 Pod。 相反，你可以使用 _负载资源_ 来替你管理一组 Pods。 这些资源配置 {{< glossary_tooltip term_id="controller" text="控制器" >}} 来确保合适类型的、处于运行状态的 Pod 个数是正确的，与你所指定的状态相一致。 -这些工作负载资源包括： +Kubernetes 提供若干种内置的工作负载资源： * [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) - （替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）； -* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/); -* 用来运行提供节点本地支撑设施（如存储驱动或网络插件）的 Pods 的 - [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)； -* 用来执行运行到结束为止的 - [Job](/zh/docs/concepts/workloads/controllers/job/) 和 + （替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）。 + `Deployment` 很适合用来管理你的集群上的无状态应用，`Deployment` 中的所有 + `Pod` 都是相互等价的，并且在需要的时候被换掉。 +* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/) + 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。 + 例如，如果你的负载会将数据作持久存储，你可以运行一个 `StatefulSet`，将每个 + `Pod` 与某个 [`PersistentVolume`](/zh/docs/concepts/storage/persistent-volumes/) + 对应起来。你在 `StatefulSet` 中各个 `Pod` 内运行的代码可以将数据复制到同一 + `StatefulSet` 中的其它 `Pod` 中以提高整体的服务可靠性。 + +* [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) + 定义提供节点本地支撑设施的 `Pods`。这些 Pods 可能对于你的集群的运维是 + 非常重要的，例如作为网络链接的辅助工具或者作为网络 + {{< glossary_tooltip text="插件" term_id="addons" >}} + 的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 `DaemonSet` + 的规约匹配，则控制面会为该 `DaemonSet` 调度一个 `Pod` 到该新节点上运行。 +* [Job](/zh/docs/concepts/workloads/controllers/job/) 和 [CronJob](/zh/docs/concepts/workloads/controllers/cron-jobs/)。 + 定义一些一直运行到结束并停止的任务。`Job` 用来表达的是一次性的任务，而 + `CronJob` 会根据其时间规划反复运行。 -你可能发现还有两种支撑概念很有用： - -* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在 - 对象的 _属主资源_ 被删除时在集群中清理这些对象。 -* [_结束后存在时间_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) - 会在 Job 结束之后的指定时间间隔之后删除它们。 +在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方 +工作负载资源。通过使用 +[定制资源定义（CRD）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)， +你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。 +例如，如果你希望运行一组 `Pods`，但要求所有 Pods 都可用时才执行操作 +（比如针对某种高吞吐量的分布式任务），你可以实现一个能够满足这一需求 +的扩展，并将其安装到集群中运行。 ## {{% heading "whatsnext" %}} @@ -93,7 +131,7 @@ As well as reading about each resource, you can learn about specific tasks that * [Run a stateless application using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/) * Run a stateful application either as a [single instance](/docs/tasks/run-application/run-single-instance-stateful-application/) or as a [replicated set](/docs/tasks/run-application/run-replicated-stateful-application/) -* [Run Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) +* [Run Automated Tasks with a `CronJob`](/docs/tasks/job/automated-tasks-with-cron-jobs/) --> 除了阅读了解每类资源外，你还可以了解与这些资源相关的任务： @@ -101,18 +139,37 @@ As well as reading about each resource, you can learn about specific tasks that * 以[单实例](/zh/docs/tasks/run-application/run-single-instance-stateful-application/) 或者[多副本集合](/zh/docs/tasks/run-application/run-replicated-stateful-application/) 的形式运行有状态的应用； -* [使用 CronJob 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/) +* [使用 `CronJob` 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/) + + +要了解 Kubernetes 将代码与配置分离的实现机制，可参阅 +[配置部分](/zh/docs/concepts/configuration/)。 + + +关于 Kubernetes 如何为应用管理 Pods，还有两个支撑概念能够提供相关背景信息： + +* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在 + 对象的 _属主资源_ 被删除时在集群中清理这些对象。 +* [_Time-to-Live_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) + 会在 Job 结束之后的指定时间间隔之后删除它们。 -一旦你的应用处于运行状态，你就可能想要 -以[服务](/zh/docs/concepts/services-networking/service/) -使之在互联网上可访问；或者对于 Web 应用而言，使用 -[Ingress](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 +一旦你的应用处于运行状态，你就可能想要以 +[`Service`](/zh/docs/concepts/services-networking/service/) +的形式使之可在互联网上访问；或者对于 Web 应用而言，使用 +[`Ingress`](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 From 9845d4e7a375655dd9c533cd2c74b80783be8bc4 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 11 Jan 2021 09:31:12 +0800 Subject: [PATCH 17/46] Fix typo in kustomization example --- .../tasks/manage-kubernetes-objects/kustomization.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md index 424b2cf581..e3093d64d9 100644 --- a/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/zh/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -518,8 +518,8 @@ spec: containers: - name: my-nginx resources: - limits: - memory: 512Mi + limits: + memory: 512Mi EOF cat <./kustomization.yaml @@ -553,11 +553,12 @@ spec: spec: containers: - image: nginx - limits: - memory: 512Mi name: my-nginx ports: - containerPort: 80 + resources: + limits: + memory: 512Mi ``` + 系统组件指标可以更好地了解系统内部发生的情况。指标对于构建仪表板和告警特别有用。 -Kubernetes 组件以 [Prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/)生成度量值。 +Kubernetes 组件以 [Prometheus 格式](https://prometheus.io/docs/instrumenting/exposition_formats/) +生成度量值。 这种格式是结构化的纯文本，旨在使人和机器都可以阅读。 @@ -25,20 +36,6 @@ Kubernetes 组件以 [Prometheus 格式](https://prometheus.io/docs/instrumentin In most cases metrics are available on `/metrics` endpoint of the HTTP server. For components that doesn't expose endpoint by default it can be enabled using `--bind-address` flag. Examples of those components: - -* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} -* {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} -* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} -* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} -* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} - -In a production environment you may want to configure [Prometheus Server](https://prometheus.io/) or some other metrics scraper -to periodically gather these metrics and make them available in some kind of time series database. - -Note that {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} also exposes metrics in `/metrics/cadvisor`, `/metrics/resource` and `/metrics/probes` endpoints. Those metrics do not have same lifecycle. - -If your cluster uses {{< glossary_tooltip term_id="rbac" text="RBAC" >}}, reading metrics requires authorization via a user, group or ServiceAccount with a ClusterRole that allows accessing `/metrics`. -For example: --> ## Kubernetes 中的指标 @@ -53,14 +50,24 @@ For example: * {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} * {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} -在生产环境中，你可能需要配置 [Prometheus 服务](https://prometheus.io/) 或 + +在生产环境中，你可能需要配置 [Prometheus 服务器](https://prometheus.io/) 或 某些其他指标搜集器以定期收集这些指标，并使它们在某种时间序列数据库中可用。 请注意，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 还会在 `/metrics/cadvisor`， `/metrics/resource` 和 `/metrics/probes` 端点中公开度量值。这些度量值的生命周期各不相同。 如果你的集群使用了 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}， -则读取指标需要通过基于用户、组或 ServiceAccount 的鉴权，要求具有允许访问 `/metrics` 的 ClusterRole。 +则读取指标需要通过基于用户、组或 ServiceAccount 的鉴权，要求具有允许访问 +`/metrics` 的 ClusterRole。 例如： ```yaml @@ -78,58 +85,69 @@ rules: ## 指标生命周期 -Alpha 指标 → 稳定指标 → 弃用指标 → 隐藏指标 → 删除 +Alpha 指标 → 稳定的指标 → 弃用的指标 → 隐藏的指标 → 删除的指标 -Alpha 指标没有稳定性保证，因此可以随时对其进行修改或者删除。 +Alpha 指标没有稳定性保证。这些指标可以随时被修改或者删除。 -稳定指标可以保证不会改变；具体而言，稳定意味着： +稳定的指标可以保证不会改变。这意味着： -* 指标本身不会被删除（或重命名） -* 指标的类型不会被更改 +* 稳定的、不包含已弃用（deprecated）签名的指标不会被删除（或重命名） +* 稳定的指标的类型不会被更改 -已弃用的指标表明该指标最终将被删除；要搞清楚对应版本，你需要检查其注解， -其中包括从哪个 kubernetes 版本开始，将不再考虑该指标。 - -过期前： - -``` -# HELP some_counter this counts things -# TYPE some_counter counter -some_counter 0 -``` - -过期后: - -``` -# HELP some_counter (Deprecated since 1.15.0) this counts things -# TYPE some_counter counter -some_counter 0 -``` +已弃用的指标最终将被删除，不过仍然可用。 +这类指标包含注解，标明其被废弃的版本。 -隐藏指标后，默认情况下，该指标不会发布以供抓取。要使用隐藏指标，你需要覆盖相关集群组件的配置。 +例如： -指标一旦删除，就不会发布。你无法通过重载配置来改变这一点。 +* 被弃用之前： + + ``` + # HELP some_counter this counts things + # TYPE some_counter counter + some_counter 0 + ``` +* 被启用之后： + + ``` + # HELP some_counter (Deprecated since 1.15.0) this counts things + # TYPE some_counter counter + some_counter 0 + ``` + + +隐藏的指标不会再被发布以供抓取，但仍然可用。 +要使用隐藏指标，请参阅[显式隐藏指标](#show-hidden-metrics)节。 + +删除的指标不再被发布，亦无法使用。 + + -## 显示隐藏指标 +## 显示隐藏指标 {#show-hidden-metrics} -综上所述，管理员可以通过设置可执行文件的命令行参数来启用隐藏指标， +如上所述，管理员可以通过设置可执行文件的命令行参数来启用隐藏指标， 如果管理员错过了上一版本中已经弃用的指标的迁移，则可以把这个用作管理员的逃生门。 -`show-hidden-metrics-for-version` 标志接受版本号作为取值，版本号给出你希望显示该发行版本中已弃用的指标。 +`show-hidden-metrics-for-version` 标志接受版本号作为取值，版本号给出 +你希望显示该发行版本中已弃用的指标。 版本表示为 x.y，其中 x 是主要版本，y 是次要版本。补丁程序版本不是必须的， 即使指标可能会在补丁程序发行版中弃用，原因是指标弃用策略规定仅针对次要版本。 @@ -226,6 +245,60 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` + +### kube-scheduler 指标 {#kube-scheduler-metrics} + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +调度器会暴露一些可选的指标，报告所有运行中 Pods 所请求的资源和期望的约束值。 +这些指标可用来构造容量规划监控面板、访问调度约束的当前或历史数据、 +快速发现因为缺少资源而无法被调度的负载，或者将 Pod 的实际资源用量 +与其请求值进行比较。 + + +kube-scheduler 组件能够辩识各个 Pod 所配置的资源 +[请求和约束](/zh/docs/concepts/configuration/manage-resources-containers/)。 +在 Pod 的资源请求值或者约束值非零时，kube-scheduler 会以度量值时间序列的形式 +生成报告。该时间序列值包含以下标签： +- 名字空间 +- Pod 名称 +- Pod 调度所处节点，或者当 Pod 未被调度时用空字符串表示 +- 优先级 +- 为 Pod 所指派的调度器 +- 资源的名称（例如，`cpu`） +- 资源的单位，如果知道的话（例如，`cores`） + + +一旦 Pod 进入完成状态（其 `restartPolicy` 为 `Never` 或 `OnFailure`，且 +其处于 `Succeeded` 或 `Failed` Pod 阶段，或者已经被删除且所有容器都具有 +终止状态），该时间序列停止报告，因为调度器现在可以调度其它 Pod 来执行。 +这两个指标称作 `kube_pod_resource_request` 和 `kube_pod_resource_limit`。 + +指标暴露在 HTTP 端点 `/metrics/resources`，与调度器上的 `/metrics` 端点 +一样要求相同的访问授权。你必须使用 +`--show-hidden-metrics-for-version=1.20` 标志才能暴露那些稳定性为 Alpha +的指标。 + ## {{% heading "whatsnext" %}} * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) -* 查看 [Kubernetes 稳定指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml)的列表 +* 查看 [Kubernetes 稳定指标](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) + 的列表 * 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) From 088f0d8bb2174dfa1fa9acef31c2eac359843e1e Mon Sep 17 00:00:00 2001 From: caodonghui Date: Tue, 12 Jan 2021 15:00:34 +0800 Subject: [PATCH 20/46] fix /zh/docs/setup/learning-environment/ --- static/_redirects | 1 + 1 file changed, 1 insertion(+) diff --git a/static/_redirects b/static/_redirects index 97f6a8b80f..ad2903935f 100644 --- a/static/_redirects +++ b/static/_redirects @@ -470,6 +470,7 @@ /docs/setup/minikube/ /docs/tasks/tools/ 302 /docs/setup/learning-environment/ /docs/tasks/tools/ 302! +/zh/docs/setup/learning-environment/ /zh/docs/tasks/tools/ 302! /docs/setup/learning-environment/kind/ /docs/tasks/tools/ 302 /docs/setup/learning-environment/minikube/ /docs/tasks/tools/ 302 /docs/setup/cri/ /docs/setup/production-environment/container-runtimes/ 301 From f4f2c74db92ecad85b61a4b8c0ee1854b6cfc3ae Mon Sep 17 00:00:00 2001 From: outofmem0ry Date: Sun, 10 Jan 2021 13:02:43 -0800 Subject: [PATCH 21/46] Fix containerd config instructions modified: content/en/docs/setup/production-environment/container-runtimes.md modified: content/ko/docs/setup/production-environment/container-runtimes.md modified: content/zh/docs/setup/production-environment/container-runtimes.md modified: content/id/docs/setup/production-environment/container-runtimes.md modified: content/ja/docs/setup/production-environment/container-runtimes.md modified: content/zh/docs/setup/production-environment/container-runtimes.md modified: content/id/docs/setup/production-environment/container-runtimes.md modified: content/ja/docs/setup/production-environment/container-runtimes.md modified: content/zh/docs/setup/production-environment/container-runtimes.md --- .../docs/setup/production-environment/container-runtimes.md | 2 +- .../docs/setup/production-environment/container-runtimes.md | 4 ++-- .../docs/setup/production-environment/container-runtimes.md | 4 ++-- .../docs/setup/production-environment/container-runtimes.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 4c69e0b9b2..84bd2cb937 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -210,7 +210,7 @@ sudo yum update -y && sudo yum install -y containerd.io ```shell ## Configure containerd sudo mkdir -p /etc/containerd -sudo containerd config default > /etc/containerd/config.toml +sudo containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell diff --git a/content/id/docs/setup/production-environment/container-runtimes.md b/content/id/docs/setup/production-environment/container-runtimes.md index bca967593c..39db9c9ed3 100644 --- a/content/id/docs/setup/production-environment/container-runtimes.md +++ b/content/id/docs/setup/production-environment/container-runtimes.md @@ -359,7 +359,7 @@ apt-get update && apt-get install -y containerd.io ```shell # Mengonfigure containerd mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell @@ -391,7 +391,7 @@ yum update -y && yum install -y containerd.io ```shell ## Mengonfigurasi containerd mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell diff --git a/content/ja/docs/setup/production-environment/container-runtimes.md b/content/ja/docs/setup/production-environment/container-runtimes.md index 372523091a..8629e2f102 100644 --- a/content/ja/docs/setup/production-environment/container-runtimes.md +++ b/content/ja/docs/setup/production-environment/container-runtimes.md @@ -351,7 +351,7 @@ apt-get update && apt-get install -y containerd.io ```shell # containerdの設定 mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell @@ -383,7 +383,7 @@ yum update -y && yum install -y containerd.io ```shell ## containerdの設定 mkdir -p /etc/containerd -containerd config default > /etc/containerd/config.toml +containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 891e0bf61a..68c2436837 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -151,7 +151,7 @@ sudo yum update -y && sudo yum install -y containerd.io ```shell ## containerd 구성 sudo mkdir -p /etc/containerd -sudo containerd config default > /etc/containerd/config.toml +sudo containerd config default | sudo tee /etc/containerd/config.toml ``` ```shell From efc3c488ea2577aee4b42158006e638f8dcd2364 Mon Sep 17 00:00:00 2001 From: Nate Reid <45366367+natereid72@users.noreply.github.com> Date: Wed, 13 Jan 2021 17:04:26 -0500 Subject: [PATCH 22/46] Update service.md --- content/en/docs/concepts/services-networking/service.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index 58d9bb9a2d..d3747323d1 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -238,7 +238,7 @@ There are a few reasons for using proxying for Services: ### User space proxy mode {#proxy-mode-userspace} -In this mode, kube-proxy watches the Kubernetes master for the addition and +In this mode, kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service it opens a port (randomly chosen) on the local node. Any connections to this "proxy port" are proxied to one of the Service's backend Pods (as reported via From 1b371ec2d6f27a3fb91b6be42b4336f8e9c38cd1 Mon Sep 17 00:00:00 2001 From: Arhell Date: Thu, 14 Jan 2021 03:02:31 +0200 Subject: [PATCH 23/46] [zh] clean up too old comments for v1.9 or before in examples --- content/zh/examples/application/deployment-patch.yaml | 2 +- content/zh/examples/application/deployment-retainkeys.yaml | 2 +- content/zh/examples/application/deployment-scale.yaml | 2 +- content/zh/examples/application/deployment-update.yaml | 2 +- content/zh/examples/application/deployment.yaml | 2 +- .../zh/examples/application/guestbook/frontend-deployment.yaml | 2 +- .../examples/application/guestbook/redis-master-deployment.yaml | 2 +- .../examples/application/guestbook/redis-slave-deployment.yaml | 2 +- content/zh/examples/application/mysql/mysql-deployment.yaml | 2 +- content/zh/examples/application/wordpress/mysql-deployment.yaml | 2 +- .../zh/examples/application/wordpress/wordpress-deployment.yaml | 2 +- 11 files changed, 11 insertions(+), 11 deletions(-) diff --git a/content/zh/examples/application/deployment-patch.yaml b/content/zh/examples/application/deployment-patch.yaml index 7b32e2fcae..af12f4cb0c 100644 --- a/content/zh/examples/application/deployment-patch.yaml +++ b/content/zh/examples/application/deployment-patch.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: patch-demo diff --git a/content/zh/examples/application/deployment-retainkeys.yaml b/content/zh/examples/application/deployment-retainkeys.yaml index b5e04f0cc1..af63f46d37 100644 --- a/content/zh/examples/application/deployment-retainkeys.yaml +++ b/content/zh/examples/application/deployment-retainkeys.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: retainkeys-demo diff --git a/content/zh/examples/application/deployment-scale.yaml b/content/zh/examples/application/deployment-scale.yaml index 68801c971d..01fe96d845 100644 --- a/content/zh/examples/application/deployment-scale.yaml +++ b/content/zh/examples/application/deployment-scale.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment diff --git a/content/zh/examples/application/deployment-update.yaml b/content/zh/examples/application/deployment-update.yaml index 18e8be65fb..1c0b9d1ab8 100644 --- a/content/zh/examples/application/deployment-update.yaml +++ b/content/zh/examples/application/deployment-update.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment diff --git a/content/zh/examples/application/deployment.yaml b/content/zh/examples/application/deployment.yaml index 2cd599218d..dbed8bc72b 100644 --- a/content/zh/examples/application/deployment.yaml +++ b/content/zh/examples/application/deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment diff --git a/content/zh/examples/application/guestbook/frontend-deployment.yaml b/content/zh/examples/application/guestbook/frontend-deployment.yaml index 50d6e1f0d4..23d64be644 100644 --- a/content/zh/examples/application/guestbook/frontend-deployment.yaml +++ b/content/zh/examples/application/guestbook/frontend-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: frontend diff --git a/content/zh/examples/application/guestbook/redis-master-deployment.yaml b/content/zh/examples/application/guestbook/redis-master-deployment.yaml index fc6f418c39..478216d1ac 100644 --- a/content/zh/examples/application/guestbook/redis-master-deployment.yaml +++ b/content/zh/examples/application/guestbook/redis-master-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: redis-master diff --git a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml index 7dcfb6c263..1a7b04386a 100644 --- a/content/zh/examples/application/guestbook/redis-slave-deployment.yaml +++ b/content/zh/examples/application/guestbook/redis-slave-deployment.yaml @@ -1,4 +1,4 @@ -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: redis-slave diff --git a/content/zh/examples/application/mysql/mysql-deployment.yaml b/content/zh/examples/application/mysql/mysql-deployment.yaml index 518457777e..419fbe03d3 100644 --- a/content/zh/examples/application/mysql/mysql-deployment.yaml +++ b/content/zh/examples/application/mysql/mysql-deployment.yaml @@ -9,7 +9,7 @@ spec: app: mysql clusterIP: None --- -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: mysql diff --git a/content/zh/examples/application/wordpress/mysql-deployment.yaml b/content/zh/examples/application/wordpress/mysql-deployment.yaml index 8b92b76f54..c6b221512d 100644 --- a/content/zh/examples/application/wordpress/mysql-deployment.yaml +++ b/content/zh/examples/application/wordpress/mysql-deployment.yaml @@ -25,7 +25,7 @@ spec: requests: storage: 20Gi --- -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: wordpress-mysql diff --git a/content/zh/examples/application/wordpress/wordpress-deployment.yaml b/content/zh/examples/application/wordpress/wordpress-deployment.yaml index d898474211..c8ed239142 100644 --- a/content/zh/examples/application/wordpress/wordpress-deployment.yaml +++ b/content/zh/examples/application/wordpress/wordpress-deployment.yaml @@ -25,7 +25,7 @@ spec: requests: storage: 20Gi --- -apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +apiVersion: apps/v1 kind: Deployment metadata: name: wordpress From f7b29716fd641484fc5e60f67f1ab2cc55da9097 Mon Sep 17 00:00:00 2001 From: Leonardo Murillo Date: Wed, 13 Jan 2021 19:47:03 -0600 Subject: [PATCH 24/46] Enhancements in clarity to access-application-cluster/connecting-frontend-backend.md (#25927) * Enhancements in clarity to docs/tasks/access-application-cluster/connecting-frontend-backend.md * Code review comments * Reverting name of service due to backed value in Dockerimage --- .../connecting-frontend-backend.md | 91 +++++++++++-------- content/en/examples/service/access/Dockerfile | 2 +- .../{hello.yaml => backend-deployment.yaml} | 6 +- ...ello-service.yaml => backend-service.yaml} | 2 + .../service/access/frontend-deployment.yaml | 27 ++++++ .../service/access/frontend-nginx.conf | 14 +++ .../service/access/frontend-service.yaml | 15 +++ .../en/examples/service/access/frontend.conf | 11 --- .../en/examples/service/access/frontend.yaml | 39 -------- 9 files changed, 114 insertions(+), 93 deletions(-) rename content/en/examples/service/access/{hello.yaml => backend-deployment.yaml} (91%) rename content/en/examples/service/access/{hello-service.yaml => backend-service.yaml} (95%) create mode 100644 content/en/examples/service/access/frontend-deployment.yaml create mode 100644 content/en/examples/service/access/frontend-nginx.conf create mode 100644 content/en/examples/service/access/frontend-service.yaml delete mode 100644 content/en/examples/service/access/frontend.conf delete mode 100644 content/en/examples/service/access/frontend.yaml diff --git a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md index bd54c71cf6..9573a1a68d 100644 --- a/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/en/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -1,22 +1,24 @@ --- -title: Connect a Front End to a Back End Using a Service +title: Connect a Frontend to a Backend Using Services content_type: tutorial weight: 70 --- -This task shows how to create a frontend and a backend -microservice. The backend microservice is a hello greeter. The -frontend and backend are connected using a Kubernetes -{{< glossary_tooltip term_id="service" >}} object. +This task shows how to create a _frontend_ and a _backend_ microservice. The backend +microservice is a hello greeter. The frontend exposes the backend using nginx and a +Kubernetes {{< glossary_tooltip term_id="service" >}} object. ## {{% heading "objectives" %}} -* Create and run a microservice using a {{< glossary_tooltip term_id="deployment" >}} object. -* Route traffic to the backend using a frontend. -* Use a Service object to connect the frontend application to the - backend application. +* Create and run a sample `hello` backend microservice using a + {{< glossary_tooltip term_id="deployment" >}} object. +* Use a Service object to send traffic to the backend microservice's multiple replicas. +* Create and run a `nginx` frontend microservice, also using a Deployment object. +* Configure the frontend microservice to send traffic to the backend microservice. +* Use a Service object of `type=LoadBalancer` to expose the frontend microservice + outside the cluster. ## {{% heading "prerequisites" %}} @@ -34,24 +36,24 @@ require a supported environment. If your environment does not support this, you The backend is a simple hello greeter microservice. Here is the configuration file for the backend Deployment: -{{< codenew file="service/access/hello.yaml" >}} +{{< codenew file="service/access/backend-deployment.yaml" >}} Create the backend Deployment: ```shell -kubectl apply -f https://k8s.io/examples/service/access/hello.yaml +kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml ``` View information about the backend Deployment: ```shell -kubectl describe deployment hello +kubectl describe deployment backend ``` The output is similar to this: ``` -Name: hello +Name: backend Namespace: default CreationTimestamp: Mon, 24 Oct 2016 14:21:02 -0700 Labels: app=hello @@ -59,7 +61,7 @@ Labels: app=hello track=stable Annotations: deployment.kubernetes.io/revision=1 Selector: app=hello,tier=backend,track=stable -Replicas: 7 desired | 7 updated | 7 total | 7 available | 0 unavailable +Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 1 max unavailable, 1 max surge @@ -80,14 +82,14 @@ Conditions: Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: -NewReplicaSet: hello-3621623197 (7/7 replicas created) +NewReplicaSet: hello-3621623197 (3/3 replicas created) Events: ... ``` -## Creating the backend Service object +## Creating the `hello` Service object -The key to connecting a frontend to a backend is the backend +The key to sending requests from a frontend to a backend is the backend Service. A Service creates a persistent IP address and DNS name entry so that the backend microservice can always be reached. A Service uses {{< glossary_tooltip text="selectors" term_id="selector" >}} to find @@ -95,42 +97,51 @@ the Pods that it routes traffic to. First, explore the Service configuration file: -{{< codenew file="service/access/hello-service.yaml" >}} +{{< codenew file="service/access/backend-service.yaml" >}} -In the configuration file, you can see that the Service routes traffic to Pods -that have the labels `app: hello` and `tier: backend`. +In the configuration file, you can see that the Service, named `hello` routes +traffic to Pods that have the labels `app: hello` and `tier: backend`. -Create the `hello` Service: +Create the backend Service: ```shell -kubectl apply -f https://k8s.io/examples/service/access/hello-service.yaml +kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml ``` -At this point, you have a backend Deployment running, and you have a -Service that can route traffic to it. +At this point, you have a `backend` Deployment running three replicas of your `hello` +application, and you have a Service that can route traffic to them. However, this +service is neither available nor resolvable outside the cluster. ## Creating the frontend -Now that you have your backend, you can create a frontend that connects to the backend. -The frontend connects to the backend worker Pods by using the DNS name -given to the backend Service. The DNS name is "hello", which is the value -of the `name` field in the preceding Service configuration file. +Now that you have your backend running, you can create a frontend that is accessible +outside the cluster, and connects to the backend by proxying requests to it. -The Pods in the frontend Deployment run an nginx image that is configured -to find the hello backend Service. Here is the nginx configuration file: +The frontend sends requests to the backend worker Pods by using the DNS name +given to the backend Service. The DNS name is `hello`, which is the value +of the `name` field in the `examples/service/access/backend-service.yaml` +configuration file. -{{< codenew file="service/access/frontend.conf" >}} +The Pods in the frontend Deployment run a nginx image that is configured +to proxy requests to the `hello` backend Service. Here is the nginx configuration file: -Similar to the backend, the frontend has a Deployment and a Service. The -configuration for the Service has `type: LoadBalancer`, which means that -the Service uses the default load balancer of your cloud provider. +{{< codenew file="service/access/frontend-nginx.conf" >}} -{{< codenew file="service/access/frontend.yaml" >}} +Similar to the backend, the frontend has a Deployment and a Service. An important +difference to notice between the backend and frontend services, is that the +configuration for the frontend Service has `type: LoadBalancer`, which means that +the Service uses a load balancer provisioned by your cloud provider and will be +accessible from outside the cluster. + +{{< codenew file="service/access/frontend-service.yaml" >}} + +{{< codenew file="service/access/frontend-deployment.yaml" >}} Create the frontend Deployment and Service: ```shell -kubectl apply -f https://k8s.io/examples/service/access/frontend.yaml +kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml +kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml ``` The output verifies that both resources were created: @@ -178,7 +189,7 @@ cluster. ## Send traffic through the frontend -The frontend and backends are now connected. You can hit the endpoint +The frontend and backend are now connected. You can hit the endpoint by using the curl command on the external IP of your frontend Service. ```shell @@ -196,17 +207,17 @@ The output shows the message generated by the backend: To delete the Services, enter this command: ```shell -kubectl delete services frontend hello +kubectl delete services frontend backend ``` To delete the Deployments, the ReplicaSets and the Pods that are running the backend and frontend applications, enter this command: ```shell -kubectl delete deployment frontend hello +kubectl delete deployment frontend backend ``` ## {{% heading "whatsnext" %}} * Learn more about [Services](/docs/concepts/services-networking/service/) * Learn more about [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) - +* Learn more about [DNS for Service and Pods](/docs/concepts/services-networking/dns-pod-service/) diff --git a/content/en/examples/service/access/Dockerfile b/content/en/examples/service/access/Dockerfile index b7b09d492a..61c8ce2831 100644 --- a/content/en/examples/service/access/Dockerfile +++ b/content/en/examples/service/access/Dockerfile @@ -1,4 +1,4 @@ FROM nginx:1.17.3 RUN rm /etc/nginx/conf.d/default.conf -COPY frontend.conf /etc/nginx/conf.d +COPY frontend-nginx.conf /etc/nginx/conf.d diff --git a/content/en/examples/service/access/hello.yaml b/content/en/examples/service/access/backend-deployment.yaml similarity index 91% rename from content/en/examples/service/access/hello.yaml rename to content/en/examples/service/access/backend-deployment.yaml index 85dff18ee1..5c95e38a3b 100644 --- a/content/en/examples/service/access/hello.yaml +++ b/content/en/examples/service/access/backend-deployment.yaml @@ -1,14 +1,15 @@ +--- apiVersion: apps/v1 kind: Deployment metadata: - name: hello + name: backend spec: selector: matchLabels: app: hello tier: backend track: stable - replicas: 7 + replicas: 3 template: metadata: labels: @@ -22,3 +23,4 @@ spec: ports: - name: http containerPort: 80 +... \ No newline at end of file diff --git a/content/en/examples/service/access/hello-service.yaml b/content/en/examples/service/access/backend-service.yaml similarity index 95% rename from content/en/examples/service/access/hello-service.yaml rename to content/en/examples/service/access/backend-service.yaml index 71344ecb8b..9262d29bb8 100644 --- a/content/en/examples/service/access/hello-service.yaml +++ b/content/en/examples/service/access/backend-service.yaml @@ -1,3 +1,4 @@ +--- apiVersion: v1 kind: Service metadata: @@ -10,3 +11,4 @@ spec: - protocol: TCP port: 80 targetPort: http +... \ No newline at end of file diff --git a/content/en/examples/service/access/frontend-deployment.yaml b/content/en/examples/service/access/frontend-deployment.yaml new file mode 100644 index 0000000000..182b0e708e --- /dev/null +++ b/content/en/examples/service/access/frontend-deployment.yaml @@ -0,0 +1,27 @@ +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: frontend +spec: + selector: + matchLabels: + app: hello + tier: frontend + track: stable + replicas: 1 + template: + metadata: + labels: + app: hello + tier: frontend + track: stable + spec: + containers: + - name: nginx + image: "gcr.io/google-samples/hello-frontend:1.0" + lifecycle: + preStop: + exec: + command: ["/usr/sbin/nginx","-s","quit"] +... \ No newline at end of file diff --git a/content/en/examples/service/access/frontend-nginx.conf b/content/en/examples/service/access/frontend-nginx.conf new file mode 100644 index 0000000000..39a911a09a --- /dev/null +++ b/content/en/examples/service/access/frontend-nginx.conf @@ -0,0 +1,14 @@ +# The identifier Backend is internal to nginx, and used to name this specific upstream +upstream Backend { + # hello is the internal DNS name used by the backend Service inside Kubernetes + server hello; +} + +server { + listen 80; + + location / { + # The following statement will proxy traffic to the upstream named Backend + proxy_pass http://Backend; + } +} diff --git a/content/en/examples/service/access/frontend-service.yaml b/content/en/examples/service/access/frontend-service.yaml new file mode 100644 index 0000000000..898a5ed51b --- /dev/null +++ b/content/en/examples/service/access/frontend-service.yaml @@ -0,0 +1,15 @@ +--- +apiVersion: v1 +kind: Service +metadata: + name: frontend +spec: + selector: + app: hello + tier: frontend + ports: + - protocol: "TCP" + port: 80 + targetPort: 80 + type: LoadBalancer +... \ No newline at end of file diff --git a/content/en/examples/service/access/frontend.conf b/content/en/examples/service/access/frontend.conf deleted file mode 100644 index 9a1f5a0ed6..0000000000 --- a/content/en/examples/service/access/frontend.conf +++ /dev/null @@ -1,11 +0,0 @@ -upstream hello { - server hello; -} - -server { - listen 80; - - location / { - proxy_pass http://hello; - } -} diff --git a/content/en/examples/service/access/frontend.yaml b/content/en/examples/service/access/frontend.yaml deleted file mode 100644 index 9f5b6b757f..0000000000 --- a/content/en/examples/service/access/frontend.yaml +++ /dev/null @@ -1,39 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: frontend -spec: - selector: - app: hello - tier: frontend - ports: - - protocol: "TCP" - port: 80 - targetPort: 80 - type: LoadBalancer ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: frontend -spec: - selector: - matchLabels: - app: hello - tier: frontend - track: stable - replicas: 1 - template: - metadata: - labels: - app: hello - tier: frontend - track: stable - spec: - containers: - - name: nginx - image: "gcr.io/google-samples/hello-frontend:1.0" - lifecycle: - preStop: - exec: - command: ["/usr/sbin/nginx","-s","quit"] From 14bcdc0bc7bb2381ced0895fd471251a1089bd9b Mon Sep 17 00:00:00 2001 From: Haleygo Date: Thu, 14 Jan 2021 09:50:00 +0800 Subject: [PATCH 25/46] only change en --- .../en/docs/concepts/cluster-administration/certificates.md | 6 +++--- content/en/docs/tasks/tls/managing-tls-in-a-cluster.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/cluster-administration/certificates.md b/content/en/docs/concepts/cluster-administration/certificates.md index 8cc45252ec..6314420c01 100644 --- a/content/en/docs/concepts/cluster-administration/certificates.md +++ b/content/en/docs/concepts/cluster-administration/certificates.md @@ -130,11 +130,11 @@ Finally, add the same parameters into the API server start parameters. Note that you may need to adapt the sample commands based on the hardware architecture and cfssl version you are using. - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.4.1/cfssl_1.4.1_linux_amd64 -o cfssl + 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.4.1/cfssljson_1.4.1_linux_amd64 -o cfssljson + 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.4.1/cfssl-certinfo_1.4.1_linux_amd64 -o cfssl-certinfo + 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. Create a directory to hold the artifacts and initialize cfssl: diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md index 62e5cfc9cf..6ea02a06af 100644 --- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -60,7 +60,7 @@ This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https:// ## Download and install CFSSL The cfssl tools used in this example can be downloaded at -[https://pkg.cfssl.org/](https://pkg.cfssl.org/). +[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases). ## Create a Certificate Signing Request From a11047c15379db7e3d99c4cc718de1ebb7884468 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 10 Jan 2021 14:47:56 +0800 Subject: [PATCH 26/46] Clean PodPreset docs, examples and links --- .../en/docs/concepts/configuration/secret.md | 1 - .../admission-controllers.md | 7 - .../en/docs/reference/glossary/podpreset.md | 18 - .../inject-data-application/podpreset.md | 323 ------------------ content/en/examples/examples_test.go | 25 -- .../examples/podpreset/allow-db-merged.yaml | 31 -- content/en/examples/podpreset/allow-db.yaml | 24 -- content/en/examples/podpreset/configmap.yaml | 14 - .../en/examples/podpreset/conflict-pod.yaml | 19 -- .../examples/podpreset/conflict-preset.yaml | 18 - content/en/examples/podpreset/merged.yaml | 25 -- .../en/examples/podpreset/multi-merged.yaml | 29 -- content/en/examples/podpreset/pod.yaml | 14 - content/en/examples/podpreset/preset.yaml | 17 - content/en/examples/podpreset/proxy.yaml | 14 - .../examples/podpreset/replicaset-merged.yaml | 31 -- content/en/examples/podpreset/replicaset.yaml | 29 -- static/_redirects | 2 - 18 files changed, 641 deletions(-) delete mode 100755 content/en/docs/reference/glossary/podpreset.md delete mode 100644 content/en/docs/tasks/inject-data-application/podpreset.md delete mode 100644 content/en/examples/podpreset/allow-db-merged.yaml delete mode 100644 content/en/examples/podpreset/allow-db.yaml delete mode 100644 content/en/examples/podpreset/configmap.yaml delete mode 100644 content/en/examples/podpreset/conflict-pod.yaml delete mode 100644 content/en/examples/podpreset/conflict-preset.yaml delete mode 100644 content/en/examples/podpreset/merged.yaml delete mode 100644 content/en/examples/podpreset/multi-merged.yaml delete mode 100644 content/en/examples/podpreset/pod.yaml delete mode 100644 content/en/examples/podpreset/preset.yaml delete mode 100644 content/en/examples/podpreset/proxy.yaml delete mode 100644 content/en/examples/podpreset/replicaset-merged.yaml delete mode 100644 content/en/examples/podpreset/replicaset.yaml diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index fbaf0c1a29..1413c05d4a 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -795,7 +795,6 @@ See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-contai Manually created secrets (for example, one containing a token for accessing a GitHub account) can be automatically attached to pods based on their service account. -See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process. ## Details diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 8d01b1d20c..0cdcbf2f36 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -669,13 +669,6 @@ allowVolumeExpansion: true For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). -### PodPreset {#podpreset} - -This admission controller injects a pod with the fields specified in a matching PodPreset. -See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and -[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset) -for more information. - ### PodSecurityPolicy {#podsecuritypolicy} This admission controller acts on creation and modification of the pod and determines if it should be admitted diff --git a/content/en/docs/reference/glossary/podpreset.md b/content/en/docs/reference/glossary/podpreset.md deleted file mode 100755 index f63187ff71..0000000000 --- a/content/en/docs/reference/glossary/podpreset.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: PodPreset -id: podpreset -date: 2018-04-12 -full_link: -short_description: > - An API object that injects information such as secrets, volume mounts, and environment variables into pods at creation time. - -aka: -tags: -- operation ---- - An API object that injects information such as secrets, volume mounts, and environment variables into {{< glossary_tooltip text="Pods" term_id="pod" >}} at creation time. - - - -This object chooses the Pods to inject information into using standard selectors. This allows the podspec definitions to be nonspecific, decoupling the podspec from environment specific configuration. - diff --git a/content/en/docs/tasks/inject-data-application/podpreset.md b/content/en/docs/tasks/inject-data-application/podpreset.md deleted file mode 100644 index 91c3c7beb6..0000000000 --- a/content/en/docs/tasks/inject-data-application/podpreset.md +++ /dev/null @@ -1,323 +0,0 @@ ---- -reviewers: -- jessfraz -title: Inject Information into Pods Using a PodPreset -min-kubernetes-server-version: v1.6 -content_type: task -weight: 60 ---- - - - -{{< feature-state for_k8s_version="v1.6" state="alpha" >}} - -This page shows how to use PodPreset objects to inject information like {{< glossary_tooltip text="Secrets" term_id="secret" >}}, volume mounts, and {{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} into Pods at creation time. - - - -## {{% heading "prerequisites" %}} - - -You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using [Minikube](https://minikube.sigs.k8s.io/docs/). -Make sure that you have [enabled PodPreset](/docs/concepts/workloads/pods/podpreset/#enable-pod-preset) in your cluster. - - - - - - -## Use Pod presets to inject environment variables and volumes - -In this step, you create a preset that has a volume mount and one environment variable. -Here is the manifest for the PodPreset: - -{{< codenew file="podpreset/preset.yaml" >}} - -The name of a PodPreset object must be a valid -[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). - -In the manifest, you can see that the preset has an environment variable definition called `DB_PORT` -and a volume mount definition called `cache-volume` which is mounted under `/cache`. The {{< glossary_tooltip text="selector" term_id="selector" >}} specifies that -the preset will act upon any Pod that is labeled `role:frontend`. - -Create the PodPreset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml -``` - -Verify that the PodPreset has been created: - -```shell -kubectl get podpreset -``` -``` -NAME CREATED AT -allow-database 2020-01-24T08:54:29Z -``` - -This manifest defines a Pod labelled `role: frontend` (matching the PodPreset's selector): - -{{< codenew file="podpreset/pod.yaml" >}} - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/pod.yaml -``` - -Verify that the Pod is running: - -```shell -kubectl get pods -``` - -The output shows that the Pod is running: - -``` -NAME READY STATUS RESTARTS AGE -website 1/1 Running 0 4m -``` - -View the Pod spec altered by the admission controller in order to see the effects of the preset -having been applied: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/merged.yaml" >}} - -The `DB_PORT` environment variable, the `volumeMount` and the `podpreset.admission.kubernetes.io` annotation -of the Pod verify that the preset has been applied. - -## Pod spec with ConfigMap example - -This is an example to show how a Pod spec is modified by a Pod preset -that references a ConfigMap containing environment variables. - -Here is the manifest containing the definition of the ConfigMap: - -{{< codenew file="podpreset/configmap.yaml" >}} - -Create the ConfigMap: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/configmap.yaml -``` - -Here is a PodPreset manifest referencing that ConfigMap: - -{{< codenew file="podpreset/allow-db.yaml" >}} - -Create the preset that references the ConfigMap: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/allow-db.yaml -``` - -The following manifest defines a Pod matching the PodPreset for this example: - -{{< codenew file="podpreset/pod.yaml" >}} - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/pod.yaml -``` - -View the Pod spec altered by the admission controller in order to see the effects of the preset -having been applied: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/allow-db-merged.yaml" >}} - -The `DB_PORT` environment variable and the `podpreset.admission.kubernetes.io` annotation of the Pod -verify that the preset has been applied. - -## ReplicaSet with Pod spec example - -This is an example to show that only Pod specs are modified by Pod presets. Other workload types -like ReplicaSets or Deployments are unaffected. - -Here is the manifest for the PodPreset for this example: - -{{< codenew file="podpreset/preset.yaml" >}} - -Create the preset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml -``` - -This manifest defines a ReplicaSet that manages three application Pods: - -{{< codenew file="podpreset/replicaset.yaml" >}} - -Create the ReplicaSet: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/replicaset.yaml -``` - -Verify that the Pods created by the ReplicaSet are running: - -```shell -kubectl get pods -``` - -The output shows that the Pods are running: - -``` -NAME READY STATUS RESTARTS AGE -frontend-2l94q 1/1 Running 0 2m18s -frontend-6vdgn 1/1 Running 0 2m18s -frontend-jzt4p 1/1 Running 0 2m18s -``` - -View the `spec` of the ReplicaSet: - -```shell -kubectl get replicasets frontend -o yaml -``` - -{{< note >}} -The ReplicaSet object's `spec` was not changed, nor does the ReplicaSet contain a -`podpreset.admission.kubernetes.io` annotation. This is because a PodPreset only -applies to Pod objects. - -To see the effects of the preset having been applied, you need to look at individual Pods. -{{< /note >}} - -The command to view the specs of the affected Pods is: - -```shell -kubectl get pod --selector=role=frontend -o yaml -``` - -{{< codenew file="podpreset/replicaset-merged.yaml" >}} - -Again the `podpreset.admission.kubernetes.io` annotation of the Pods -verifies that the preset has been applied. - -## Multiple Pod presets example - -This is an example to show how a Pod spec is modified by multiple Pod presets. - - -Here is the manifest for the first PodPreset: - -{{< codenew file="podpreset/preset.yaml" >}} - -Create the first PodPreset for this example: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/preset.yaml -``` - -Here is the manifest for the second PodPreset: - -{{< codenew file="podpreset/proxy.yaml" >}} - -Create the second preset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/proxy.yaml -``` - -Here's a manifest containing the definition of an applicable Pod (matched by two PodPresets): - -{{< codenew file="podpreset/pod.yaml" >}} - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/pod.yaml -``` - -View the Pod spec altered by the admission controller in order to see the effects of both presets -having been applied: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/multi-merged.yaml" >}} - -The `DB_PORT` environment variable, the `proxy-volume` VolumeMount and the two `podpreset.admission.kubernetes.io` -annotations of the Pod verify that both presets have been applied. - -## Conflict example - -This is an example to show how a Pod spec is not modified by a Pod preset when there is a conflict. -The conflict in this example consists of a `VolumeMount` in the PodPreset conflicting with a Pod that defines the same `mountPath`. - -Here is the manifest for the PodPreset: - -{{< codenew file="podpreset/conflict-preset.yaml" >}} - -Note the `mountPath` value of `/cache`. - -Create the preset: - -```shell -kubectl apply -f https://k8s.io/examples/podpreset/conflict-preset.yaml -``` - -Here is the manifest for the Pod: - -{{< codenew file="podpreset/conflict-pod.yaml" >}} - -Note the volumeMount element with the same path as in the PodPreset. - -Create the Pod: - -```shell -kubectl create -f https://k8s.io/examples/podpreset/conflict-pod.yaml -``` - -View the Pod spec: - -```shell -kubectl get pod website -o yaml -``` - -{{< codenew file="podpreset/conflict-pod.yaml" >}} - -You can see there is no preset annotation (`podpreset.admission.kubernetes.io`). Seeing no annotation tells you that no preset has not been applied to the Pod. - -However, the -[PodPreset admission controller](/docs/reference/access-authn-authz/admission-controllers/#podpreset) -logs a warning containing details of the conflict. -You can view the warning using `kubectl`: - -```shell -kubectl -n kube-system logs -l=component=kube-apiserver -``` - -The output should look similar to: - -``` -W1214 13:00:12.987884 1 admission.go:147] conflict occurred while applying podpresets: allow-database on pod: err: merging volume mounts for allow-database has a conflict on mount path /cache: -v1.VolumeMount{Name:"other-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*v1.MountPropagationMode)(nil), SubPathExpr:""} -does not match -core.VolumeMount{Name:"cache-volume", ReadOnly:false, MountPath:"/cache", SubPath:"", MountPropagation:(*core.MountPropagationMode)(nil), SubPathExpr:""} - in container -``` - -Note the conflict message on the path for the VolumeMount. - -## Deleting a PodPreset - -Once you don't need a PodPreset anymore, you can delete it with `kubectl`: - -```shell -kubectl delete podpreset allow-database -``` -The output shows that the PodPreset was deleted: -``` -podpreset "allow-database" deleted -``` diff --git a/content/en/examples/examples_test.go b/content/en/examples/examples_test.go index d653d8303e..012a2acaa7 100644 --- a/content/en/examples/examples_test.go +++ b/content/en/examples/examples_test.go @@ -32,7 +32,6 @@ import ( "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apimachinery/pkg/util/yaml" - // "k8s.io/apiserver/pkg/util/feature" "k8s.io/kubernetes/pkg/api/legacyscheme" "k8s.io/kubernetes/pkg/apis/apps" @@ -56,9 +55,6 @@ import ( "k8s.io/kubernetes/pkg/apis/rbac" rbac_validation "k8s.io/kubernetes/pkg/apis/rbac/validation" - "k8s.io/kubernetes/pkg/apis/settings" - settings_validation "k8s.io/kubernetes/pkg/apis/settings/validation" - "k8s.io/kubernetes/pkg/apis/storage" storage_validation "k8s.io/kubernetes/pkg/apis/storage/validation" @@ -73,7 +69,6 @@ import ( _ "k8s.io/kubernetes/pkg/apis/networking/install" _ "k8s.io/kubernetes/pkg/apis/policy/install" _ "k8s.io/kubernetes/pkg/apis/rbac/install" - _ "k8s.io/kubernetes/pkg/apis/settings/install" _ "k8s.io/kubernetes/pkg/apis/storage/install" ) @@ -111,7 +106,6 @@ func initGroups() { networking.GroupName, policy.GroupName, rbac.GroupName, - settings.GroupName, storage.GroupName, } @@ -296,11 +290,6 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { case *rbac.ClusterRoleBinding: // clusterolebinding does not accept namespace errors = rbac_validation.ValidateClusterRoleBinding(t) - case *settings.PodPreset: - if t.Namespace == "" { - t.Namespace = api.NamespaceDefault - } - errors = settings_validation.ValidatePodPreset(t) case *storage.StorageClass: // storageclass does not accept namespace errors = storage_validation.ValidateStorageClass(t) @@ -518,20 +507,6 @@ func TestExampleObjectSchemas(t *testing.T) { "node-problem-detector-configmap": {&apps.DaemonSet{}}, "termination": {&api.Pod{}}, }, - "podpreset": { - "allow-db": {&settings.PodPreset{}}, - "allow-db-merged": {&api.Pod{}}, - "configmap": {&api.ConfigMap{}}, - "conflict-pod": {&api.Pod{}}, - "conflict-preset": {&settings.PodPreset{}}, - "merged": {&api.Pod{}}, - "multi-merged": {&api.Pod{}}, - "pod": {&api.Pod{}}, - "preset": {&settings.PodPreset{}}, - "proxy": {&settings.PodPreset{}}, - "replicaset-merged": {&api.Pod{}}, - "replicaset": {&apps.ReplicaSet{}}, - }, "pods": { "commands": {&api.Pod{}}, "init-containers": {&api.Pod{}}, diff --git a/content/en/examples/podpreset/allow-db-merged.yaml b/content/en/examples/podpreset/allow-db-merged.yaml deleted file mode 100644 index 7f52cc1fa4..0000000000 --- a/content/en/examples/podpreset/allow-db-merged.yaml +++ /dev/null @@ -1,31 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - ports: - - containerPort: 80 - env: - - name: DB_PORT - value: "6379" - - name: duplicate_key - value: FROM_ENV - - name: expansion - value: $(REPLACE_ME) - envFrom: - - configMapRef: - name: etcd-env-config - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/allow-db.yaml b/content/en/examples/podpreset/allow-db.yaml deleted file mode 100644 index 2c511e650d..0000000000 --- a/content/en/examples/podpreset/allow-db.yaml +++ /dev/null @@ -1,24 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: allow-database -spec: - selector: - matchLabels: - role: frontend - env: - - name: DB_PORT - value: "6379" - - name: duplicate_key - value: FROM_ENV - - name: expansion - value: $(REPLACE_ME) - envFrom: - - configMapRef: - name: etcd-env-config - volumeMounts: - - mountPath: /cache - name: cache-volume - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/configmap.yaml b/content/en/examples/podpreset/configmap.yaml deleted file mode 100644 index 806a880bff..0000000000 --- a/content/en/examples/podpreset/configmap.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: v1 -kind: ConfigMap -metadata: - name: etcd-env-config -data: - number_of_members: "1" - initial_cluster_state: new - initial_cluster_token: DUMMY_ETCD_INITIAL_CLUSTER_TOKEN - discovery_token: DUMMY_ETCD_DISCOVERY_TOKEN - discovery_url: http://etcd_discovery:2379 - etcdctl_peers: http://etcd:2379 - duplicate_key: FROM_CONFIG_MAP - REPLACE_ME: "a value" - diff --git a/content/en/examples/podpreset/conflict-pod.yaml b/content/en/examples/podpreset/conflict-pod.yaml deleted file mode 100644 index 6949f7e162..0000000000 --- a/content/en/examples/podpreset/conflict-pod.yaml +++ /dev/null @@ -1,19 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - ports: - - containerPort: 80 - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/conflict-preset.yaml b/content/en/examples/podpreset/conflict-preset.yaml deleted file mode 100644 index a2ad96c48a..0000000000 --- a/content/en/examples/podpreset/conflict-preset.yaml +++ /dev/null @@ -1,18 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: allow-database -spec: - selector: - matchLabels: - role: frontend - env: - - name: DB_PORT - value: "6379" - volumeMounts: - - mountPath: /cache - name: other-volume - volumes: - - name: other-volume - emptyDir: {} - diff --git a/content/en/examples/podpreset/merged.yaml b/content/en/examples/podpreset/merged.yaml deleted file mode 100644 index 97c022c86c..0000000000 --- a/content/en/examples/podpreset/merged.yaml +++ /dev/null @@ -1,25 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - ports: - - containerPort: 80 - env: - - name: DB_PORT - value: "6379" - volumes: - - name: cache-volume - emptyDir: {} - diff --git a/content/en/examples/podpreset/multi-merged.yaml b/content/en/examples/podpreset/multi-merged.yaml deleted file mode 100644 index 7fcaae62e3..0000000000 --- a/content/en/examples/podpreset/multi-merged.yaml +++ /dev/null @@ -1,29 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" - podpreset.admission.kubernetes.io/podpreset-proxy: "resource version" -spec: - containers: - - name: website - image: nginx - volumeMounts: - - mountPath: /cache - name: cache-volume - - mountPath: /etc/proxy/configs - name: proxy-volume - ports: - - containerPort: 80 - env: - - name: DB_PORT - value: "6379" - volumes: - - name: cache-volume - emptyDir: {} - - name: proxy-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/pod.yaml b/content/en/examples/podpreset/pod.yaml deleted file mode 100644 index b6b4e60d6e..0000000000 --- a/content/en/examples/podpreset/pod.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: website - labels: - app: website - role: frontend -spec: - containers: - - name: website - image: nginx - ports: - - containerPort: 80 - diff --git a/content/en/examples/podpreset/preset.yaml b/content/en/examples/podpreset/preset.yaml deleted file mode 100644 index f300289c82..0000000000 --- a/content/en/examples/podpreset/preset.yaml +++ /dev/null @@ -1,17 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: allow-database -spec: - selector: - matchLabels: - role: frontend - env: - - name: DB_PORT - value: "6379" - volumeMounts: - - mountPath: /cache - name: cache-volume - volumes: - - name: cache-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/proxy.yaml b/content/en/examples/podpreset/proxy.yaml deleted file mode 100644 index d854475ac2..0000000000 --- a/content/en/examples/podpreset/proxy.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: settings.k8s.io/v1alpha1 -kind: PodPreset -metadata: - name: proxy -spec: - selector: - matchLabels: - role: frontend - volumeMounts: - - mountPath: /etc/proxy/configs - name: proxy-volume - volumes: - - name: proxy-volume - emptyDir: {} diff --git a/content/en/examples/podpreset/replicaset-merged.yaml b/content/en/examples/podpreset/replicaset-merged.yaml deleted file mode 100644 index 95cf846ebc..0000000000 --- a/content/en/examples/podpreset/replicaset-merged.yaml +++ /dev/null @@ -1,31 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: frontend - labels: - app: guestbook - role: frontend - annotations: - podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version" -spec: - containers: - - name: php-redis - image: gcr.io/google_samples/gb-frontend:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - volumeMounts: - - mountPath: /cache - name: cache-volume - env: - - name: GET_HOSTS_FROM - value: dns - - name: DB_PORT - value: "6379" - ports: - - containerPort: 80 - volumes: - - name: cache-volume - emptyDir: {} - diff --git a/content/en/examples/podpreset/replicaset.yaml b/content/en/examples/podpreset/replicaset.yaml deleted file mode 100644 index e9d49a9d1d..0000000000 --- a/content/en/examples/podpreset/replicaset.yaml +++ /dev/null @@ -1,29 +0,0 @@ -apiVersion: apps/v1 -kind: ReplicaSet -metadata: - name: frontend -spec: - replicas: 3 - selector: - matchLabels: - role: frontend - matchExpressions: - - {key: role, operator: In, values: [frontend]} - template: - metadata: - labels: - app: guestbook - role: frontend - spec: - containers: - - name: php-redis - image: gcr.io/google_samples/gb-frontend:v3 - resources: - requests: - cpu: 100m - memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns - ports: - - containerPort: 80 diff --git a/static/_redirects b/static/_redirects index d6626accc0..6a0fee8a4a 100644 --- a/static/_redirects +++ b/static/_redirects @@ -278,7 +278,6 @@ /docs/tasks/manage-stateful-set/deleting-a-statefulset/ /docs/tasks/run-application/delete-stateful-set/ 301 /docs/tasks/manage-stateful-set/scale-stateful-set/ /docs/tasks/run-application/scale-stateful-set/ 301 /docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/ /docs/tasks/run-application/upgrade-pet-set-to-stateful-set/ 301 -/docs/tasks/run-application/podpreset/ /docs/tasks/inject-data-application/podpreset/ 301 /docs/tasks/run-application/update-api-object-kubectl-patch/ /docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/ 301 /docs/tasks/stateful-sets/deleting-pods/ /docs/tasks/run-application/force-delete-stateful-set-pod/ 301 /docs/tasks/troubleshoot/debug-init-containers/ /docs/tasks/debug-application-cluster/debug-init-containers/ 301 @@ -388,7 +387,6 @@ /docs/user-guide/persistent-volumes/index /docs/concepts/storage/persistent-volumes/ 301 /docs/user-guide/persistent-volumes/index.md /docs/concepts/storage/persistent-volumes/ 301 /docs/user-guide/persistent-volumes/walkthrough/ /docs/tasks/configure-pod-container/configure-persistent-volume-storage/ 301 -/docs/user-guide/pod-preset/ /docs/concepts/workloads/pods/podpreset/ 301 /docs/user-guide/pod-security-policy/ /docs/concepts/policy/pod-security-policy/ 301 /docs/user-guide/pod-states/ /docs/concepts/workloads/pods/pod-lifecycle/ 301 /docs/user-guide/pod-templates/ /docs/concepts/workloads/pods/#pod-templates 301 From bfd90bff5f3ba78e8f545ec860f5c5717e6ae6af Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sat, 2 Jan 2021 23:07:59 +0900 Subject: [PATCH 27/46] Ko: Second Korean l10n work for release-1.20 - Update outdated files in the dev-1.20-ko.2(p1) (#25915) - Update outdated files in the dev-1.20-ko.2(p2) (#25916) - Fix issue with links to already translated ko documents (#25991) - Translate reference/glossary/dynamic-volume-provisioning.md in Korean (#26047) Co-authored-by: seokho-son Co-authored-by: Jerry Park Co-authored-by: santachopa --- .../community/static/cncf-code-of-conduct.md | 62 ++++---- .../control-plane-node-communication.md | 2 +- .../concepts/cluster-administration/_index.md | 2 +- .../kubelet-garbage-collection.md | 5 +- .../cluster-administration/system-metrics.md | 32 ++-- .../docs/concepts/configuration/configmap.md | 3 - .../ko/docs/concepts/configuration/secret.md | 2 +- .../docs/concepts/overview/kubernetes-api.md | 4 +- .../working-with-objects/common-labels.md | 13 +- .../concepts/policy/pod-security-policy.md | 30 +++- .../docs/concepts/policy/resource-quotas.md | 2 +- .../scheduling-eviction/kube-scheduler.md | 4 +- .../connect-applications-service.md | 2 +- content/ko/docs/concepts/workloads/_index.md | 75 ++++++--- .../workloads/controllers/cron-jobs.md | 34 ++++ .../concepts/workloads/controllers/job.md | 15 +- .../ko/docs/concepts/workloads/pods/_index.md | 30 ++++ .../workloads/pods/init-containers.md | 6 +- .../pods/pod-topology-spread-constraints.md | 6 +- content/ko/docs/reference/_index.md | 6 +- .../feature-gates.md | 10 +- .../glossary/dynamic-volume-provisioning.md | 19 +++ .../ko/docs/reference/glossary/kube-proxy.md | 4 +- .../ko/docs/reference/kubectl/cheatsheet.md | 10 +- content/ko/docs/reference/kubectl/overview.md | 12 +- .../reference/using-api/client-libraries.md | 1 + .../container-runtimes.md | 30 +++- .../tools/kubeadm/self-hosting.md | 8 +- .../production-environment/tools/kubespray.md | 5 +- .../windows/intro-windows-in-kubernetes.md | 4 +- .../configure-access-multiple-clusters.md | 6 +- ...port-forward-access-application-cluster.md | 30 +++- .../administer-cluster/access-cluster-api.md | 2 +- .../kubeadm/kubeadm-upgrade.md | 18 ++- .../debug-pod-replication-controller.md | 4 +- .../tasks/extend-kubectl/kubectl-plugins.md | 2 +- .../manage-hugepages/scheduling-hugepages.md | 21 +-- .../kustomization.md | 11 +- .../ko/docs/tasks/tools/install-kubectl.md | 4 +- .../basic-stateful-set.md | 2 +- .../stateful-application/zookeeper.md | 2 +- .../expose-external-ip-address.md | 149 +++++++++--------- 42 files changed, 437 insertions(+), 252 deletions(-) create mode 100644 content/ko/docs/reference/glossary/dynamic-volume-provisioning.md diff --git a/content/ko/community/static/cncf-code-of-conduct.md b/content/ko/community/static/cncf-code-of-conduct.md index 6e3c838fe8..804c5632fd 100644 --- a/content/ko/community/static/cncf-code-of-conduct.md +++ b/content/ko/community/static/cncf-code-of-conduct.md @@ -2,44 +2,44 @@ https://github.com/cncf/foundation/blob/master/code-of-conduct.md --> ## CNCF 커뮤니티 행동 강령 v1.0 -### 참여자 행동 강령 +### 기여자 행동 강령 -본 프로젝트의 기여자 및 유지 관리자로서, 환영하는 분위기의 공개 커뮤니티를 -육성하기 위하여, 저희는 이슈를 보고하고, 기술 요청을 작성하며, 문서를 업데이트하며, -pull 요청 또는 패치를 제출하고, 다른 활동에 참여하는 -모든 분들을 존중하겠다고 약속드립니다. +본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의 +커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트, +풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는 +모든 분들을 존중할 것을 약속합니다. -저희는 경험 수준, 성별, 성 정체성과 표현, 성적 지향, -장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는 -국적에 상관 없이 모두가 괴롭힘 없는 환경에서 -본 프로젝트에 참여하도록 최선을 다하고 있습니다. +우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression), +성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, +또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에 +참여할 수 있도록 최선을 다하고 있습니다. -참여자에게 금지하는 행동의 예는 다음과 같습니다.: +참여자에게 금지하는 행위의 예시는 다음과 같습니다. -* 성적 언어 또는 이미지 사용 -* 개인적인 공격 -* 시비 걸기 또는 모욕/경멸적인 코멘트 -* 공적 및 사적 괴롭힘 -* 분명한 허락을 받지 않은 타인의 사적 정보 출판, - 예를 들어 물리적 또는 전자 주소 -* 다른 비윤리적 또는 비전문적인 행동 +- 성적인 언어 또는 이미지 사용 +- 인신 공격 +- 도발적이거나 모욕/경멸적인 코멘트 +- 공개적이거나 사적인 괴롭힘 +- 타인의 주소 및 전자주소와 같은 개인 정보의 + 동의 없는 공개 +- 기타 비윤리적이거나 비전문적인 행동 -프로젝트 유지 관리자는 본 행동 강령을 위반하는 코멘트, 협약, 강령, -위키 수정, 이슈와 다른 참여자를 제거, 수정, 삭제할 권한과 -책임을 가집니다. 본 행동 강령을 적용하여, 프로젝트 유지 관리자는 본 -프로젝트를 유지하는 모든 상황에 공정하고 일관적으로 이러한 원칙들을 -적용하기 위해 헌신해야 합니다. 프로젝트 유지 관리자는 -행동 강령이 프로젝트 팀에서 영구적으로 사라지도록 하거나 강요해서는 안됩니다. +프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit), +코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정, +거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의 +모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다. +행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서 +영구적으로 제적될 수 있습니다. -본 행동 강령은 프로젝트 공간과 개인이 프로젝트 또는 -그 커뮤니티를 대표하는 공적 공간에 모두 적용됩니다. +본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트 +또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다. -Kubernetes에서의 폭력, 학대 또는 기타 허용되지 않는 행동 사례는 이메일 주소 를 통해 [Kubernetes 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)로 신고하실 수 있습니다. 다른 프로젝트는 CNCF 프로젝트 관리자 또는 저희 중재자인 Mishi Choudhary에게 이메일 으로 연락하십시오. +쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 으로 문의해 주시기 바랍니다. -본 행동강령은 참여자 Contributor Covenant (http://contributor-covenant.org)의 -버전 1.2.0을 적용하였으며, -해당 내용은 여기 http://contributor-covenant.org/version/1/2/0/에서 확인할 수 있습니다. +본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서 +제공하는 버전 1.2.0을 적용하였으며, 해당 내용은 +https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다. -### CNCF 커뮤니티 행동 강령 +### CNCF 이벤트 행동 강령 -CNCF 이벤트는 리눅스 재단의 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/) 을 따르며, 해당 내용은 이벤트 페이지에서 확인할 수 있습니다. 본 강령은 위 정책과 호환할 수 있도록 설계되었으며, 또한 사건에 따라 더 많은 세부 내용을 포함합니다. \ No newline at end of file +CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/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 2fdaf7599c..36ece0d6d2 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. 이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을 사용한다. -마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다. +마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다. ### API 서버에서 노드, 파드 및 서비스로의 통신 diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index 5ca2ce5aca..1442a5da01 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -60,7 +60,7 @@ no_list: true ### kubelet 보안 * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + * [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) ## 선택적 클러스터 서비스 diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 228e0af585..95ea899cbb 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,4 +1,5 @@ --- + title: kubelet 가비지(Garbage) 수집 설정하기 content_type: concept weight: 70 @@ -6,7 +7,7 @@ weight: 70 -가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. +가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. 별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다. @@ -20,7 +21,7 @@ weight: 70 쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 라이프사이클을 관리한다. -이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다: +이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다. `HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는 디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한 이미지들을 삭제한다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index b897a0e79a..03eb904ee3 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -1,18 +1,19 @@ --- title: 쿠버네티스 컨트롤 플레인에 대한 메트릭 + + + + content_type: concept weight: 60 -aliases: -- controller-metrics.md --- 시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. -쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다. - - +쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다. +이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다. @@ -49,18 +50,20 @@ rules: ## 메트릭 라이프사이클 -알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제 +알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭 알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. -안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다. +안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다. +* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다. +* 안정적인 메트릭의 유형(type)은 수정되지 않는다. -* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다 -* 메트릭 유형은 수정되지 않는다 +사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다. +이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다. -사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다. +예를 들면, -사용 중단되기 전에는 아래와 같다. +* 사용 중단 이전에는 다음과 같다. ``` # HELP some_counter this counts things @@ -68,7 +71,7 @@ rules: some_counter 0 ``` -사용 중단된 이후에는 아래와 같다. +* 사용 중단 이후에는 다음과 같다. ``` # HELP some_counter (Deprecated since 1.15.0) this counts things @@ -76,9 +79,9 @@ some_counter 0 some_counter 0 ``` -메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다. +히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. -메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다. +삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다. ## 히든 메트릭 표시 @@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` + ### kube-scheduler 메트릭 {{< feature-state for_k8s_version="v1.20" state="alpha" >}} diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index fc67ab2f82..73fcf62b98 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. 캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. - 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 모든 요청을 리디렉션할 수 있다. 따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의 @@ -262,12 +261,10 @@ data: immutable: true ``` -{{< note >}} 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나 `data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다. -{{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 557fb50397..f120b0002d 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -349,7 +349,7 @@ data: 부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다. -- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. +- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 854147597b..026e0e007c 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -17,8 +17,8 @@ card: 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공한다. -쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예: -파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다. +쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예: +파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다. 대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/) 커맨드 라인 인터페이스 또는 API를 사용하는 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index b67a524a7f..09f70af30c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -58,14 +58,14 @@ metadata: ## 애플리케이션과 애플리케이션 인스턴스 -애플리케이션은 동일한 쿠버네티스 클러스터에, +애플리케이션은 동일한 쿠버네티스 클러스터에, 심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에 -워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다. +WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다. -애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. -예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, -애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 -`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 +애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. +예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, +애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 +`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다. ## 예시 @@ -169,4 +169,3 @@ metadata: ``` MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다. - diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 0ea3f087e3..e3c67a4ff9 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -1,4 +1,7 @@ --- + + + title: 파드 시큐리티 폴리시 content_type: concept weight: 30 @@ -213,12 +216,17 @@ kubectl-user create -f- <}} 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 -[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다. -쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}} +[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다. +쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 집합을 나타낸다. -파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고 -해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서 -심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 -최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다. +쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다. +예를 들어, 일단 파드가 클러스터에서 실행되고 나서 +해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에 +심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 +최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다. -그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다. +그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다. 대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다. 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를 구성한다. -이러한 워크로드 리소스에는 다음이 포함된다. +쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다. -* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) - (레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체); -* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/); -* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는 - 파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) -* 완료될 때까지 실행되는 작업에 대한 - [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및 - [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/) +* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) + (레거시 리소스 + {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체). + `Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우, + 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다. +* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는 + 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가 + 데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와 + [`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다. + 전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의 + 다른 `Pods` 로 데이터를 복제할 수 있다. +* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다. + 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다. + 예를 들면, 네트워킹 지원 도구 또는 + {{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다. + `DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다, + 컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다. +* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및 + [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은 + 실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면, + 잡은 단 한 번의 작업을 나타낸다. -관련성을 찾을 수 있는 두 가지 지원 개념도 있다. -* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 - 제거된 후 클러스터에서 오브젝트를 정리한다. -* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 - 완료된 이후 정의된 시간이 경과되면 잡을 제거한다. +더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드 +리소스도 찾을 수 있다. +[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면, +쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를 +추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되 +_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은), +사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다. ## {{% heading "whatsnext" %}} 각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다. -* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) +* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/) 또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행 -* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) +* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) + +코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는, +[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다. + +다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는 +두 가지 개념이다. +* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 + 제거된 후 클러스터에서 오브젝트를 정리한다. +* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는 + 잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다. 일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로 사용하거나, 웹 애플리케이션의 경우에만 [인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다. - -[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의 -메커니즘에 대해 알아볼 수도 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 19995d83ce..ed29659a7e 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -1,4 +1,8 @@ --- + + + + title: 크론잡 content_type: concept weight: 80 @@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는 이 예시를 더 자세히 설명한다.) +### 크론 스케줄 문법 + +``` +# ┌───────────── 분 (0 - 59) +# │ ┌───────────── 시 (0 - 23) +# │ │ ┌───────────── 일 (1 - 31) +# │ │ │ ┌───────────── 월 (1 - 12) +# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지; +# │ │ │ │ │ 특정 시스템에서는 7도 일요일) +# │ │ │ │ │ +# │ │ │ │ │ +# * * * * * +``` + + +| 항목 | 설명 | 상응 표현 | +| ------------- | ------------- |------------- | +| @yearly (or @annually) | 매년 1월 1일 자정에 실행 | 0 0 1 1 * | +| @monthly | 매월 1일 자정에 실행 | 0 0 1 * * | +| @weekly | 매주 일요일 자정에 실행 | 0 0 * * 0 | +| @daily (or @midnight) | 매일 자정에 실행 | 0 0 * * * | +| @hourly | 매시 0분에 시작 | 0 * * * * | + + +예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다. + +`0 0 13 * 5` + +크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다. + ## 크론잡의 한계 {#cron-job-limitations} 크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 5c505a3286..0f04051ff1 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -1,4 +1,7 @@ --- + + + title: 잡 content_type: concept feature: @@ -35,6 +38,7 @@ weight: 50 ```shell kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml ``` +출력 결과는 다음과 같다. ``` job.batch/pi created ``` @@ -44,6 +48,7 @@ job.batch/pi created ```shell kubectl describe jobs/pi ``` +출력 결과는 다음과 같다. ``` Name: pi Namespace: default @@ -88,6 +93,7 @@ Events: pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') echo $pods ``` +출력 결과는 다음과 같다. ``` pi-5rwd7 ``` @@ -100,7 +106,7 @@ pi-5rwd7 ```shell kubectl logs $pods ``` -다음과 유사하게 출력된다. +출력 결과는 다음과 같다. ```shell 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` @@ -395,10 +401,11 @@ spec: 잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_. 삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다. -``` +```shell kubectl get job old -o yaml ``` -``` +출력 결과는 다음과 같다. +```yaml kind: Job metadata: name: old @@ -417,7 +424,7 @@ spec: 시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해 새 잡에서 `manualSelector: true` 를 지정해야 한다. -``` +```yaml kind: Job metadata: name: new diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 6dce0bfcee..265f971816 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -1,4 +1,6 @@ --- + + title: 파드 content_type: concept weight: 10 @@ -189,6 +191,34 @@ spec: 시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을 확장할 수 있게 한다. +## 파드 갱신 및 교체 + +이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드 +템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신 +갱신된 템플릿을 기반으로 신규 파드를 생성한다. + +쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다. +동작 중인 파드의 필드를 갱신하는 것도 가능하다. +그러나, +[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및 +[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은 +파드 갱신 작업에는 다음과 같은 제약이 있다. + +- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는 + `namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다. + 그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는 + 갱신만 허용한다. +- `metadata.deletionTimestamp` 가 설정된 경우, + `metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다. +- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`, + `spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는 + 변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다. +- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만 + 허용한다. + + 1. 지정되지 않은 필드를 양수로 설정; + 1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신. + ## 리소스 공유와 통신 파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을 diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 3267f5b04d..c1e3943178 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -1,4 +1,6 @@ --- + + title: 초기화 컨테이너 content_type: concept weight: 40 @@ -47,9 +49,9 @@ weight: 40 또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다. -만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을 +만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을 한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다. -모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을 +모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을 초기화하고 평소와 같이 실행한다. ## 초기화 컨테이너 사용하기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 2cd28660d0..b927895575 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -66,7 +66,7 @@ graph TB API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다. -``` +```yaml apiVersion: v1 kind: Pod metadata: @@ -290,7 +290,7 @@ graph BT - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. - 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. -기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서 +기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, @@ -315,7 +315,7 @@ profiles: {{< note >}} 기본 스케줄링 제약 조건에 의해 생성된 점수는 -[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에 +[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에 의해 생성된 점수와 충돌 할 수 있다. `PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서 이 플러그인을 비활성화 하는 것을 권장한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 8f2f5c48a6..14fee6ee9c 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -1,5 +1,7 @@ --- title: 레퍼런스 + + linkTitle: "레퍼런스" main_menu: true weight: 70 @@ -16,7 +18,7 @@ content_type: concept ## API 레퍼런스 -* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 레퍼런스 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 ## API 클라이언트 라이브러리 @@ -33,7 +35,7 @@ content_type: concept ## CLI 레퍼런스 * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. - * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. + * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 컴포넌트 레퍼런스 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 78d54badce..ad9c9a45de 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 @@ -419,10 +419,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 - 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 + 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 + 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. - 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 + 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. -`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다. @@ -508,7 +508,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다. --`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)을 참조한다. +-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다. - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다. - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다. - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. @@ -582,7 +582,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. - `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다. -- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. +- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. 자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. - `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다. diff --git a/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md b/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md new file mode 100644 index 0000000000..ad5f3f2691 --- /dev/null +++ b/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md @@ -0,0 +1,19 @@ +--- +title: 동적 볼륨 프로비저닝(Dynamic Volume Provisioning) +id: dynamicvolumeprovisioning +date: 2018-04-12 +full_link: /ko/docs/concepts/storage/dynamic-provisioning +short_description: > + 사용자가 스토리지 볼륨의 자동 생성을 요청할 수 있게 해준다. + +aka: +tags: +- core-object +- storage +--- + 사용자가 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 자동 생성을 요청할 수 있게 해준다. + + + +동적 프로비저닝은 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없다. 대신 사용자 요청에 따라 자동으로 스토리지를 프로비저닝한다. 동적 볼륨 프로비저닝은 API 오브젝트인 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 기반으로 한다. 이 스토리지클래스는 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 및 {{< glossary_tooltip text="볼륨 플러그인" term_id="volume-plugin" >}}에 전달할 파라미터 세트를 프로비저닝하는 볼륨 플러그인을 참조한다. + diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md index 7281e6f4c5..c82ef7d968 100755 --- a/content/ko/docs/reference/glossary/kube-proxy.md +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -18,10 +18,10 @@ tags: -[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는 +[kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. -kube-proxy는 운영 체제에 가용한 패킷 +kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 1613791ddf..7db5ce3bdb 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -356,8 +356,8 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 `-o=custom-columns=<명세>` | 쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력 `-o=custom-columns-file=<파일명>` | `<파일명>`파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력 `-o=json` | JSON 형식의 API 오브젝트 출력 -`-o=jsonpath=<템플릿>` | [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 -`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath=<템플릿>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 `-o=name` | 리소스 명만 출력하고 그 외에는 출력하지 않음 `-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 `-o=yaml` | YAML 형식의 API 오브젝트 출력 @@ -395,10 +395,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 ## {{% heading "whatsnext" %}} -* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자. +* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자. -* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다. +* [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다. -* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다. +* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다. * 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다. diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index e86a5579b7..7ddfe5b095 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -119,7 +119,7 @@ kubectl [command] [TYPE] [NAME] [flags] `version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. `wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. -명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ## 리소스 타입 @@ -188,7 +188,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 출력 옵션 -특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ### 출력 서식화 @@ -207,8 +207,8 @@ kubectl [command] [TYPE] [NAME] -o `-o custom-columns=` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다. `-o custom-columns-file=` | `` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다. `-o json` | JSON 형식의 API 오브젝트를 출력한다. -`-o jsonpath=